Cool. Post some of your old 'BASIC AND machine code' on Github so we can check it out.
Not likely since the computers I wrote for were decades ago, stored on tape which would have long since worn out, and I don't have the paperwork anymore.
You mean cassette tapes? Wow. That's really ancient. You're talking about the first year (or less) of Apple II, since floppy disk drives came out fairly quick afterwards. Which tells me few things: you must have only had access to Integer BASIC then; there were virtually no programming tools on the market.
(hint: Mine were faster,
Which part, and how? I'm just curious about the math part. Character output and keyboard input I'm sure were lightning fast (for the day).
held more data
That's not really up to the program you wrote. Just depends on how much memory you had (which must have been 48K. I'm assuming you're not referring to storage, which would be negligible if you only had cassette tapes.
, and structured into a more useful form on screen).
What the heck does this mean? Are you talking about your UI? How pretty things are shown on screen? Normally, programmers talk about structures when referring to the data, not how something manifests on screen.
Well, let's see what info I'll reveal - because there are some people who would use such information to try to find out who I am. Which normally I wouldn't even care about, but considering some of the crazy things I seen some people write, I think I'll be a bit more conservative about it. And if anyone does happen to know who I am, consider that a signal that I don't approve of them telling anyone else.
First, it wasn't an Apple, though it was during the Apple II+ period. I just pointed out it was better than Apple programs I had seen (at least that weren't really expensive and thus out of the price range of the typical teacher). At the time, at least where I was, teachers were just starting to get computers for their use, but only a few. And they didn't know what to do with them!
If I gave the BASIC name (or the computer name) it could narrow things down too much. I was not writing on the typical computers people thought of at the time. I didn't get an Apple until the Apple IIgs, long afterwards. BTW, this was also where I learned it wasn't how popular a computer was that mattered the most when it came to good software. It also wasn't how powerful it was either. It was the programming.
My math was done by MC routines. At the touch of a key you could get the averages of each student in a class either with every grade counting the same or using the weighted grades if you created those. I do not recall the details now, but it seemed like a simple enough matter at the time to calculate the grades either way. Certainly no errors ever showed up when I finished. The MC also printed most of the stuff to the screen (with BASIC back then, you could see the lines being drawn one by one when you had a lot of data to display, especially if there were calculations going on at the same time).
Machine code was entered via another app. It was actually highly praised as letting people enter either the actual hex numbers for the code, or the code itself (like "Ld A" or something like that). You could do code breaks, see how data would change as it went through, etc. I read other people, using popular computers, saying they wish they had something like it. Just one of those labors of love someone took the time to make. Don't recall the name, but I sometimes coded using the hex value and other times the other way on the same app.
There was a little peek and poke with my program, but as I recall, this was only for saving and loading. Since it used a cassette, normally an save operation would save the entire program plus data. Very time-consuming. So I came up with the trick of fooling the computer into thinking the program started where, in actuality, the data started so only that was saved (unless you wanted to save both together - that was a choice). When loading back in, it would just have to load the new data to replace whatever class you had finished (and saved).
Debugging was initially done with the app, then through actual use.
The BASIC program would provide my menus - hit a key to show a particular class, or an individual student, etc, and it would call a MC routine to calculate and show the information.
No idea, at this point, what memory area the MC occupied.
I didn't do decimals or fractions, which was probably the only limitation compared to the typical programs like mine back then (actually, most didn't do fractions). Grades were whole numbers and could be from zero to 254 as I recall, though, obviously few would need that! But it was just as easy to go to that as to go to 100 and it allowed for flexibility - and certainly for ordinary extra credit on a test.
I approached the project simply enough. I didn't like any of the grade book apps I found so I decided to write my own. Interestingly, I learned most of stuff I needed from a database program I had bought which was quite clever - and in the manual, he included the parts of program that were in BASIC as well as the part that were written in MC. So a lot of stuff he needed to do were things I needed to do. So I copied and adjusted as needed. For other things unique to my program, I read and asked questions, solving one thing at a time. My program started in all BASIC and then I converted as I learned how to do things.
Mine was faster than others mostly because of the MC. Most programs of this type weren't doing that. Well, unless you wanted to spend a LOT of money.
The program did hold more data because of the program, not available memory - and my first version only had 16k available. And I'm not counting what you could pull in off a floppy disk or something - just what could be held in memory at one time.
Let me see what I can recall, starting with the programs I found for sale that were not super expensive (though they might cost as much as $40-50 which, after adjusting for inflation, would be a lot more today!
The ones I recall seeing topped out at 40 kids in a class (mine allowed 46 - because that's all I could show on one screen with the display at the time).
The others topped out at 30 grades/student - which is great, but mine topped at at 66, because combined with their name, that was all I could show on one screen, with their average grade.
Now, you couldn't maximize these numbers - more students meant fewer grades for each when dealing with just 16k, but here is an idea of the range in that limited space:
You could have a total of 279 students (divided into different classes since only 46 could be in one class) and each could receive 5 grades. Not much, but for some teachers, that's enough. And not many teachers have that many students anyway. But take the number of students down to 46 and you can give each of them 66 grades.
Most programs had you load one class in at a time from the floppy disk. That wasn't practical with a cassette system. So I allowed them to load a bunch of classes at once (note the example of 279 students - which would require at least 7 classes). All loaded at once. In my own work, I may have 6 classes with a total of 180 kids.
Which brings me to the way I saved memory. Other apps stored grades as floating point numbers. But, if I recall correctly, that took 5 bytes. I stored grades as one of the 256 code values for 8-bit machines - taking just 1 byte. I also saved smaller amounts by using variables in the BASIC section. If I saw a bunch of things like. "Goto 10", I'd set up something like, "Let A = 10". Then everything else would be "Goto A". One byte, verses the 5 for the number 10 being floating point and that number would also take two bytes for each digit - so I saved 6 bytes each time.
This did slow down the BASIC portion a little, but nothing that needed to be fast was in BASIC. Remember, when you only have 16k, even a small savings is a sizable percentage of the total.
As for the structure on the screen, the problem with other apps is that they didn't consider what teachers wanted to see - all at once. At the time, teachers were mostly using paper grade books, but there was one really good thing about them - you could see a LOT all at one time. Usually all the kids in a class and you could go across the row and see all their grades. None of the apps I saw did this. For example, an Apple app I tried only showed 7 students at a time! And, at most, maybe 12 grades for each (I'm pretty sure it was much less than that). So lots of scrolling, both horizontal and vertical to see what I could see all at once on a paper grade book! That gets annoying fast!
With mine, you could see all 46 kids in a class at once with either their average or the results of any one test. Or you could bring up any one student with every test and their average.
It wasn't pretty, but it was clear. And seeing the information this way was way more important than "pretty".
BTW, while I was self-taught - and just did little things, one of my brothers was also self-taught but he did big things, writing one program in particular that was in high demand by certain businesses. It was the only one of its kind because, like me, he was writing to fit the needs of his original job. He could make $20,000 in a week (again, would be worth much more now after inflation is factored in).
Same basic approach, but he had a richer clientele!
Well it’s all quiet on the Waytools front. We now await the clarity or otherwise of the great May 2019 update.
DBK would probably note that there’s half a month to go, and he’ll rightly note the end of the month will depend on whether you count time via GMT, UTC, Pacific Time etc.
As a former customer who, despite all, still wants a small keyboard, I hope the news is good, clear, definitive and useful.
We shall see whether it is so, for quality is the primary concern of Waytools etc etc etc etc and we wouldn’t have it any other way given the focus on quality is more important than complaints etc etc (insert more MK-style language here).
Well, let's see what info I'll reveal - because there are some people who would use such information to try to find out who I am. Which normally I wouldn't even care about, but considering some of the crazy things I seen some people write, I think I'll be a bit more conservative about it. And if anyone does happen to know who I am, consider that a signal that I don't approve of them telling anyone else.
First, it wasn't an Apple, though it was during the Apple II+ period. I just pointed out it was better than Apple programs I had seen (at least that weren't really expensive and thus out of the price range of the typical teacher). At the time, at least where I was, teachers were just starting to get computers for their use, but only a few. And they didn't know what to do with them!
If I gave the BASIC name (or the computer name) it could narrow things down too much. I was not writing on the typical computers people thought of at the time. I didn't get an Apple until the Apple IIgs, long afterwards. BTW, this was also where I learned it wasn't how popular a computer was that mattered the most when it came to good software. It also wasn't how powerful it was either. It was the programming.
...
The BASIC program would provide my menus - hit a key to show a particular class, or an individual student, etc, and it would call a MC routine to calculate and show the information.
What are you trying to cover? What do you think it will reveal? It just seems you're throwing any detailed discussion into murky waters. I don't need to know what you named your BASIC program or how it operates in general, and possibly not even your system. Just the CPU you used, because I'm just curious at how you wrote the machine language code. So, are you able to say what CPU it was? I'm familiar with several of the era: Zilog Z80, Intel 8080, 8088, Moto 6800?
If you can't even reveal that, then what year (approximately) did you write your machine code? If cassette tape was in usage at the time, that's a short window. They were temporary measure for the home market in late, late 70s before displaced by floppy in very early 80s. So that windows must have been around 1979-1980.
There was a little peek and poke with my program, but as I recall, this was only for saving and loading. Since it used a cassette, normally an save operation would save the entire program plus data. Very time-consuming. So I came up with the trick of fooling the computer into thinking the program started where, in actuality, the data started so only that was saved (unless you wanted to save both together - that was a choice). When loading back in, it would just have to load the new data to replace whatever class you had finished (and saved).
Peeks and pokes are ways to read and write value to memory. How in God's name did you use them to initiate a routine to record things and save? No wonder it was time consuming. You can peek and poke every memory address, it will not do anything except crash your computer.
As far as cassettes are concerned. Did you use parity and/or error checking? If so, it must have increased the size of your program and data by three-fold (or more). If not, reading and writing anything must have been horrendously unreliable.
My math was done by MC routines. At the touch of a key you could get the averages of each student in a class either with every grade counting the same or using the weighted grades if you created those. I do not recall the details now, but it seemed like a simple enough matter at the time to calculate the grades either way. Certainly no errors ever showed up when I finished. The MC also printed most of the stuff to the screen (with BASIC back then, you could see the lines being drawn one by one when you had a lot of data to display, especially if there were calculations going on at the same time).
Forgive my ignorance, but what is 'MC'? Is this short for machine code? If by 'MC routines' you mean 'machine code routines', yes, that's what I'd like to talk about. You seem to make only a passing reference to it, abbreviating it even. But it's that very 'MC routines' -- the math routines that had stumped Wozniak, Jobs, engineers at Apple for years before Bill Gates dedicated a team to write that and finish out the full BASIC that became Applesoft. Another great milestone for Apple II was Visicalc, which is, if you think about it, nothing more than large math package that happens to display interesting things if you enter some numbers.
You seem to make light of your achievement. If you had created a specialized math 'routines' (however simple and what CPU it was for -- if it was an 8-bit CPU used around the same era as the 6502), I'd love to know about it.
Any math, precision or otherwise, floating point or otherwise were difficult to do on Apple II. Those 8-bit CPUs, the 6502 or others of its era, can only do two arithmetic ops -- adding and subtracting. Specifically, increment (adding 1) or decrement (subtracting 1). Anything more complicated than this, like 11 + 17 for example, would require you to write some custom math functions. Even starting with a non-zero number, like 10, would mean taking an empty register and incrementing it one by one until you got to 10, and storing that somewhere. Division is traditionally done by continually subtracting 2 until remainder is < 2. Multiplication the other way. Each method takes up valuable cycles. These days with 5Ghz cpus common, cycles are cheap. But in those days, they were precious.
The crude methods are stable, but too slow to be practical. Or you can go all out with bit-flipping trickery like Bill Atkinson when he wrote QuickDraw, but that requires you to be at the top of your boolean math game. You're not Atkinson, Kahuna. But that's okay... no one is. Thus most methods are somewhere in between -- it has to be. I want to know to which side your 'MC routines' lean.
I didn't do decimals or fractions, which was probably the only limitation compared to the typical programs like mine back then (actually, most didn't do fractions). Grades were whole numbers and could be from zero to 254 as I recall, though, obviously few would need that! But it was just as easy to go to that as to go to 100 and it allowed for flexibility - and certainly for ordinary extra credit on a test.
You don't understand the meaning of decimals, which means power of 10, versus binary which is power of 2. So, you didn't do floating point, just whole numbers. You only used 0-254 -- which are decimals, by the way. Why 0-254, not 0-255? Did you do negative numbers? One byte numbers doing both positive and negative will limit you to -127 -> +127. My first primary question is: How did you display those numbers?
You make it seem like if you just throw 0xff (hex) into the display memory, it automagically appears as 255 (decimal). How did you convert the binary hex into decimal number, and vice versa? How did you add these binary numbers, subtract them, multiply them, divide them. And how did you store them, convert them to decimal, and display them?
Again, the CPU don't know how to do any of that. None of that automatically happens. All has to be meticulously programmed. I just want to know how you programmed all that. You don't need to show me any source code. I can fill in the opcodes if you can provide me a concise description, maybe even a loose description.
No idea, at this point, what memory area the MC occupied.
In the case of Apple II, the ROM reserves a chunk of memory for devices, lo-re and hi-res graphics, BASIC reservers a big chunk for runtime. You would have had to divide userland memory into two parts: for your BASIC program and machine language code. After all that, there's really only a few places where you can safely store anything without clobbering everything, even with the maximum 48K.
But you mention you had 16K, which makes me wonder where in the world you hid your machine language code?
I'll stop here. There's just too much that says nothing but raise more questions than answering anything, even after sifting through all the self-congratulatory comments which are moot since he won't reveal any detail of the system.
Kahuna, your babbling post tells me (and any programmer out there) that you have no idea what you're talking about. Not only can you not tell me anything about your math 'routines', it's obvious you don't even know some of the basic programming terms, yet you throw them about so freely in wrong contexts. You don't seem to know the difference between machine language coding vs assembly. No one in all my years has developed machine code using manual input, peek and poke and assembly -- and I'm sure you don't even know why.
If there is a morsel of truth in what Kahuna posted, any programmer out there please tell me, because I certainly can't find it.
Actually, I’d base on the time in California since that is where they are located.
Sure, no probs, I've just seen you go over various times and dates in reference to when an update might or might not be coming.
Perhaps that was during the first year when I was still a customer, maybe you've given up trying to rationalise when a time period does or doesn't end, and whether or not Waytools should or shouldn't have given an update during the often vague timeframe in which they loosely specify without any spot-on specifics when they will or won't be coming forth and be forthcoming with an update (or not).
Or something like that. Comms from Waytools get blurry in the memory, they're so similar and dissimilar at the same time, it's kind of like a best of times and worst of times situation blended together in one big nothing burger of McDonalds, Wendys, Burger King and Five Guys at the same time, yet from a multitude of multiverses all at the same time.
We await Waytools weighing in without waywardness and with a great weight of clarity, which will be a first.
Whenever that may be - Californian time will be just fine. Half a month to go before May ends.
If you can't even reveal that, then what year (approximately) did you write your machine code? If cassette tape was in usage at the time, that's a short window. They were temporary measure for the home market in late, late 70s before displaced by floppy in very early 80s. So that windows must have been around 1979-1980.
There was a little peek and poke with my program, but as I recall, this was only for saving and loading.
Peeks and pokes are ways to read and write value to memory. How in God's name did you use them to initiate a routine to record things and save? No wonder it was time consuming. You can peek and poke every memory address, it will not do anything except crash your computer.
As far as cassettes are concerned. Did you use parity and/or error checking? If so, it must have increased the size of your program and data by three-fold (or more). If not, reading and writing anything must have been horrendously unreliable.
My math was done by MC routines. At the touch of a key you could get the averages of each student in a class either with every grade counting the same or using the weighted grades if you created those.
I didn't do decimals or fractions, which was probably the only limitation compared to the typical programs like mine back then (actually, most didn't do fractions). Grades were whole numbers and could be from zero to 254 as I recall, though, obviously few would need that! But it was just as easy to go to that as to go to 100 and it allowed for flexibility - and certainly for ordinary extra credit on a test.
You don't understand the meaning of decimals, which means power of 10, versus binary which is power of 2. So, you didn't do floating point, just whole numbers. You only used 0-254 -- which are decimals, by the way. Why 0-254, not 0-255? Did you do negative numbers? One byte numbers doing both positive and negative will limit you to -127 -> +127. My first primary question is: How did you display those numbers?
You make it seem like if you just throw 0xff (hex) into the display memory, it automagically appears as 255 (decimal). How did you convert the binary hex into decimal number, and vice versa? How did you add these binary numbers, subtract them, multiply them, divide them. And how did you store them, convert them to decimal, and display them?
But you mention you had 16K, which makes me wonder where in the world you hid your machine language code?
Kahuna, your babbling post tells me (and any programmer out there) that you have no idea what you're talking about. Not only can you not tell me anything about your math 'routines', it's obvious you don't even know some of the basic programming terms, yet you throw them about so freely in wrong contexts. You don't seem to know the difference between machine language coding vs assembly. No one in all my years has developed machine code using manual input, peek and poke and assembly -- and I'm sure you don't even know why.
If there is a morsel of truth in what Kahuna posted, any programmer out there please tell me, because I certainly can't find it.
There are a couple morsels.
I used cassettes for storage up until about 1983. Parity? I cant recall. If there was any parity it would presumably have been part of the chipset that interfaced with the tape drive. The Commodore cassette drive moved data at about 400bps - not Kbps, not Mbps, not Gbps...just plain old bps The modulation at that rate is slow enough to be very reliable. I captured old C64 cassettes into Pro Tools (a digital audio workstation) 30 years after they had been recorded, and the signal looked fine, well above the noise floor, it would be no problem to recover the data if needed.
The line about 'peeks and pokes to save and load' seems like nonsense on the surface, but could be he is remembering inaccurately or mixing some things together. The purpose of peek and poke generally was to store values in registers, which were typically used to store executable instructions, data values, or to define a behavior of the machine which was set by constantly polling the various registers.
Perhaps whatever computer he was using (I too question the validity of concealing the make of the computer, as if anyone could ID a person by that fact) had a register which could be poked to indicate 'start read from tape' or 'start write to tape', although most systems had BASIC commands to accomplish that, ie, LOAD"*",8,1 to get the directory from a 1541 disk drive, so that seems like a poor interpretation.
The other way to interpret 'peeks and pokes to save and load' would be to infer he had written a BASIC bootstrap routine that poked all the machine code values comprising a load/save machine language subroutine from a DATA array into memory and then executed the machine code via an MS BASIC style 'SYS' command, ie, SYS49152, which would tell the CPU to execute a machine language subroutine starting at address 49152. But that seems totally unnecessary. Every machine that had Microsoft BASIC on it had load/save commands to do all that hard work for the user. And I do not detect in Kahuna the skillz to write any machine language subroutine from scratch so it must have been someone elses code (there was plenty available in magazines at the time).
The last interpretation I can think of is a slight variation of what I just said, which is where he could be slightly misremembering or mis-stating what he did. If you stored data as binary values in registers, which he claims he was doing, then you might want to write those registers out to tape or disk, so you might set up a loop in BASIC to PEEK through all the memory addresses to obtain the values and then write them as a 'file' (in the loosest sense of that word - a data stream with some bytes to indicate end of stream) to tape or disk. This kind of task was fairly common and trivial, so I could envision him having written a simple BASIC program where he poked some data into a sequence of memory addresses, and then peeked through those addresses to store the data on tape.
As far as the binary math and related business logic issues, I totally agree, that is non-trivial for anyone operating at the level of a BASIC programmer, and given the amount of memory that the business logic would use to implement conversions and manipulation of values and so forth, it would probably be pointless to implement that way, though I could imagine a guy who is teaching himself BASIC programming doing it just for the exercise.
So overall, I am skeptical of his memory of what he actually implemented vs what someone else might have implemented which he merely used. I detect a slight amount of self-aggrandizing. lolz
None of which matters. What is relevant here is that Kahuna clearly has no idea how a modern development team manages architecting modern software, thus his rambling opinions on the notions of Waytools 'freeing up space in firmware' and so forth are just nonsense. Among the top ten most annoying things about Kahuna, surely a contender for the #1 position would be how rigorously he will assert an opinion about a subject which he clearly knows nothing about.
> What are you trying to cover? What do you think it will reveal? It just seems you're throwing any detailed discussion into murky waters.
As I said, I'd prefer to make it as difficult as possible for anyone to figure out who I am while still answering. Anything that narrows down the computer would also narrow down what to search for since one can find references on the net about me and things I wrote. Regardless, I sure gave you a lot of detail!
> Peeks and pokes are ways to read and write value to memory. How in God's name did you use them to initiate a routine to record things and save? No wonder it was time consuming. You can peek and poke every memory address, it will not do anything except crash your computer.
Well, it didn't crash the computer so I guess what I did worked. The peeks and pokes simply let me see where the data started, then I could poke that into the place that stored where to start saving. It was just like two spots. No big deal. Anytime I loaded a saved data section in, it put the proper numbers back in. Thus the built-in save routine only saved what I wanted, rather than the whole program every time. Too long ago now to get more specific than that, but it worked - and worked every time.
> reading and writing anything must have been horrendously unreliable.
The only reliability issue would be the tape itself. These were just ordinary cassettes and anyone using this kind of system knew it was always a good idea to make more than one copy in case the tape had a bad spot in it.
> Forgive my ignorance, but what is 'MC'? Is this short for machine code? Yep.
> You seem to make light of your achievement. If you had created a specialized math 'routines' (however simple and what CPU it was for -- if it was an 8-bit CPU used around the same era as the 6502), I'd love to know about it. It was 8-bit. I make light of it because it didn't seem like a big deal to me. And I know it worked. Maybe the computer did some stuff I wasn't aware of. Maybe I'm taking a simpler approach than you are imagining. At this point, I have no idea what the code actually was or the Basic part either! But it worked.
> You're not Atkinson, Kahuna. But that's okay... no one is. Thus most methods are somewhere in between -- it has to be. I want to know to which side your 'MC routines' lean. Sorry, but I'm not going to remember much from nearly 40 years ago! And, as I said, I wasn't a trained programmer. I simply found things I wanted to do and methodically found answers for how to do them, copying things I was pointed to. Not doing it full time so not likely to retain the details so many years later! I'm not even going to remember the basic steps for a lot of it.
> You don't understand the meaning of decimals, which means power of 10, versus binary which is power of 2. I'm a teacher, so when I refer to decimals and fractions, I'm not talking about the computer stuff, but whether a teacher can give only whole number scores (1, 2, 3, etc) or decimal/fraction scores (95.3 or 95-1/2). My program didn't allow either. Most teachers don't use them, but some do. So that was a limitation if a teacher used my program and wanted to include those.
>Why 0-254, not 0-255? Because 255 was reserved for something else. Specifically "NG" (for no grade). This gave the teacher an option when entering scores when someone didn't take the test. In some cases, they may be excused so you don't want it averaged in at all (thus NG). In other cases a student who misses a test may be given a zero by the teacher so they could do that if they wished. Like I said, I was a teacher and knew the kinds of things they wanted. You'd be surprised at how many similar programs didn't allow for that.
No negative scores. There may be tests where that is necessary, but I've never run into them so, if some teacher needed that, that would be another limitation of my program - a small one.
> How did you display those numbers? As numbers: 99, 100, 96, whatever.
> How did you convert the binary hex into decimal number, and vice versa? Don't recall the code to do it, but in basic, I think it would have been something like, "Print Code "D". Or maybe it was Val Code "D". Too long ago to recall. When a teacher entered a grade (in Basic because speed was not an issue for that), if they entered "100", it was stored as whatever character in the ascii set that was 100.
I certainly don't recall the code process for getting the averages, etc. You are asking for specifics about something I wrote decades ago and which, not being trained to program, I figured out the hard way, with no reason to need to remember later once better computers - and programs - came out. At that point instead of programming from scratch, I was figured out ways to make spreadsheets do what I wanted instead.
> But you mention you had 16K, which makes me wonder where in the world you hid your machine language code? Don't know. I know there were memory locations which revealed where a program would start in memory, another for where data started. Don't know if the machine code was stored in with Basic or if there was another setting in memory that stored where that was. For example, maybe the computer stored things in three sets - Basic, MC, Data. But I sure don't remember now!
> even after sifting through all the self-congratulatory comments which are moot since he won't reveal any detail of the system.
??? A little ways back you were saying I made light of some big accomplishment!
You asked what I did and I answered as best I could decades after the fact! And yes, I am proud of what I did. So?
As for the system, I'll just add that it was not a 6502.
And now we get to what I think was the purpose of your original questions - which wasn't to really learn how I did things:
> Kahuna, your babbling post tells me (and any programmer out there) that you have no idea what you're talking about.
Yet the program worked.
> Not only can you not tell me anything about your math 'routines'
Right, decades later I can't recall.
> it's obvious you don't even know some of the basic programming terms
Maybe because I wasn't trained as a programmer? Just a hunch. But I see snobbism rearing it's head!
> If there is a morsel of truth in what Kahuna posted, any programmer out there please tell me, because I certainly can't find it. Ah, and now the insinuation that what I said isn't "truth"?
I've just seen you go over various times and dates in reference to when an update might or might not be coming.
Perhaps that was during the first year when I was still a customer, maybe you've given up trying to rationalise when a time period does or doesn't end, and whether or not Waytools should or shouldn't have given an update during the often vague timeframe in which they loosely specify without any spot-on specifics when they will or won't be coming forth and be forthcoming with an update (or not).
No, not rationalizing. I was giving all reasonable possibilities. Using anything besides California time, when they are in California, wouldn't make much sense.
But, typical of those times I did point out reasonable possibilities, it was because they were reasonable, such as saying "end of the week" could be taken as meaning Friday, Saturday, or Sunday. Thus not fair to criticize them for not giving an update for "next week" when we have only reached Tuesday or Wednesday of that week! It was posts like that I was responding to.
But I'll give you some bad news about May 31st. It's a Friday. And, yes, it the update doesn't come until after the first few hours of Saturday (say 3:00 AM) - because even though it is Saturday, it would also be part of Mark's Friday workday - if it takes that long, I would not be surprised if they waited until Tuesday. No, I'm not saying that is okay. I'm saying what won't surprise me. The reason would be that, at least in the past, they had tests running which they would go over at a weekly Monday meeting where they make decisions. Then to get a big update out may take into the next day.
I really think they should avoid that. But it isn't my main worry. That would be the fact that they have already missed a BUNCH of updates since the last one so until I see it, I'll be worried that it won't happen. And yes, WT knows how I feel about that!
> If there is a morsel of truth in what Kahuna posted, any programmer out there please tell me, because I certainly can't find it.
Ah, and now the insinuation that what I said isn't "truth"?
I threw out a couple morsels in your defense. That said, you should excuse people who do not find you to be the quintessence of credibility, because, on average, you are not credible.
> The line about 'peeks and pokes to save and load' seems like nonsense on the surface, but could be he is remembering inaccurately or mixing some things together. The purpose of peek and poke generally was to store values in registers
Ah, that sounds like the right word, "registers". BTW, did you know it is perfectly possible to write a program without always knowing all the "proper" terminology" - especially decades later?
There were some that the computer automatically filled in, though you could force changes with a poke. So, for example, one said where the end of a basic program was - it would, of course, be changed every time you changed the size of the program (I do not know if the end of the basic section also included the MC or if that was a separate number). Another said where the Basic program began. I believe another was where the data ended ("ramtop"?). Anyway the computer also kept track of where the app started and, normally, would save everything starting with the basic program and all through the data section. Which wasted time when using a cassette. So I simply peeked into the register that said where the basic program ended and where the data ended, then poked those values into the places so the computer thought it should only start the save at the address where the data was. Of course, I had stuff that saved the original values and put them back when the save was done!
>The other way to interpret 'peeks and pokes to save and load' would be to infer he had written a BASIC bootstrap routine that poked all the machine code values comprising a load/save machine language subroutine from a DATA array....
Nope. As I said, this was a very tiny bit of peeking and poking of specific registers to control what was saved. Once that was done, I just activated the standard Save command.
> The last interpretation I can think of is a slight variation of what I just said, which is where he could be slightly misremembering or mis-stating what he did. If you stored data as binary values in registers, which he claims he was doing....
No, I don't think I was claiming that, unless there is some confusion over terminology. My data wasn't peeked or poked. It was all stored in one long string, which was set up when the user first set up their classes. I believe I named it "D$", but I may be wrong. But it was just one long string.
> What is relevant here is that Kahuna clearly has no idea how a modern development team manages architecting modern software
Well, there is that detail that I was writing on my own! So a team of ONE.
> thus his rambling opinions on the notions of Waytools 'freeing up space in firmware' and so forth are just nonsense.
Well, maybe you can explain what is nonsense about it? Or is one of the things experts do is fail to explain things?
I don't think I need to be an expert in how teams work together to figure out that if your available memory is full, it makes it much harder to fix problems!
I've just seen you go over various times and dates in reference to when an update might or might not be coming.
Perhaps that was during the first year when I was still a customer, maybe you've given up trying to rationalise when a time period does or doesn't end, and whether or not Waytools should or shouldn't have given an update during the often vague timeframe in which they loosely specify without any spot-on specifics when they will or won't be coming forth and be forthcoming with an update (or not).
No, not rationalizing. I was giving all reasonable possibilities. Using anything besides California time, when they are in California, wouldn't make much sense.
But, typical of those times I did point out reasonable possibilities, it was because they were reasonable, such as saying "end of the week" could be taken as meaning Friday, Saturday, or Sunday. Thus not fair to criticize them for not giving an update for "next week" when we have only reached Tuesday or Wednesday of that week! It was posts like that I was responding to.
But I'll give you some bad news about May 31st. It's a Friday. And, yes, it the update doesn't come until after the first few hours of Saturday (say 3:00 AM) - because even though it is Saturday, it would also be part of Mark's Friday workday - if it takes that long, I would not be surprised if they waited until Tuesday. No, I'm not saying that is okay. I'm saying what won't surprise me. The reason would be that, at least in the past, they had tests running which they would go over at a weekly Monday meeting where they make decisions. Then to get a big update out may take into the next day.
I really think they should avoid that. But it isn't my main worry. That would be the fact that they have already missed a BUNCH of updates since the last one so until I see it, I'll be worried that it won't happen. And yes, WT knows how I feel about that!
Oh well, as you effectively state, Waytools is extremely consistent in being inconsistent with their update timeframes, so it we take their consistent inconsistency into account, we should get the May 31 update sometime in the weeks before June 30, although as June 30 ends on a Sunday, it may well be the case that the update timeframe, much like a GR timeframe, could easily stretch to July 31, a Wednesday, although that may then take us into August sometime, which could then stretch until August 31, which sadly ends on a Saturday, and thus because of weekend timeframes and server availability and the sanity levels of those who occupy CEO positions, things might stretch into September, with Sept 30 being a Monday, which could then stretch the entire week into October, although that makes any date in October possible, and because October 31 is a Thursday, we might see things stretch into November, but with November 30 ending on a Saturday, we might see things stretch into December, but as December 31 is on a Tuesday, we see how things might easily stretch into the new decade that will be 2020.
All of that said, we might get an update on Thursday, May 30, which will avoid the whole May 31 situation which stretches Mark's workday into Saturday at 3am, but given the next update is only one update of the presumably many needed before GR generally becomes the general release date, we catapult ourselves back into the timeframes above, all of which end their monthly timeframes either on a week day or weekend, all of which might mean stretching either to the end of the week (and thus a new month), or ending on a weekend, which would by necessity of weekends generally only being times during which work may or may not cease, thus pushing things into a new week, that we might, or might not reasonably (or otherwise) expect a universe of possibilities to indicate virtually any timeframe, because it is reasonable to note that the "end of the week" could be taken as meaning Friday, Saturday or Sunday, or if Mark's Sunday weekend workday stretches into 3am Monday, I would not be surprised if a delay was delayed until Tuesday, which could stretch to Wednesday, or Thursday, or Friday, or Saturday, or even Sunday, which, if Mark's Sunday weekend workday stretches into 3am Monday, I would not be surprised if a delay was delayed until Tuesday, which could, you know, stretch to Wednesday, or Thursday, or Friday, or Saturday, or even Sunday.
As the Cylons said, all of this has happened before and will happen again. It's the great cycle. Game of Thrones wishes not to stop the wheel, but to break it (which we might see next episode in the series finale), but of course, if we break it (like a TREG test unit TextBlade playing up in some way), this will start the cycle all over again, and that's how we get to the year 2022 and Catch 2022!
But... I'm repeating myself, like a delete key that keeps on deleting until everything is deleted.
I'm a teacher, so when I refer to decimals and fractions, I'm not talking about the computer stuff, but whether a teacher can give only whole number scores (1, 2, 3, etc) or decimal/fraction scores (95.3 or 95-1/2). My program didn't allow either. Most teachers don't use them, but some do. So that was a limitation if a teacher used my program and wanted to include those.
The word 'decimal' is not 'computer stuff'. It's a general term for numbers representation, specifically power of 10 vs. another, as in: binary (power of 2), octal (power of 8), hex (power of 16). You're the only one using it to compare with fractionals, whole/absolute/integer numbers. This is basic English I'm talking about, not computer jargons.
> How did you display those numbers? As numbers: 99, 100, 96, whatever.
I figured you might take that question completely out of context. Most people would read and understand the context of the question. I even explained this context before and after the question. But along with this:
> How did you convert the binary hex into decimal number, and vice versa?
Don't recall the code to do it, but in basic, I think it would have been something like, "Print Code "D". Or maybe it was Val Code "D". Too long ago to recall. When a teacher entered a grade (in Basic because speed was not an issue for that), if they entered "100", it was stored as whatever character in the ascii set that was 100.
It tells me you stored numbers (e.g. 100) in ASCII format, which means a value of 100 which can be stored as one byte in the form 0x64 was instead used three bytes (ASCII for '1', ASCII for '0', ASCII for '0') + END_MARKER for a total of four bytes. In short, you stored an integer number value (100) as a string ("100").
Not only is this the worst way of wasting memory, it still doesn't explain how you did any calculations. It would mean that you'd have to:
ROUTINE A: load a register with first digit ('1) subtract the ASCII baseline (the number right before '1') load another register with second digit '0' subtract the ASCII baseline load another register with third digit '0' subtract the ASCII baseline add first register with second add first register with third save the result in memory repeat ROUTINE A for second number ... load a register with first result load another register with second result add first register with second
everytime you want to add two numbers. For sake of brevity, I didn't bother noting how many valuable cycles each line would waste. So, waste of memory and waste of cycles... it's a wonder anything ran at all.
I certainly don't recall the code process for getting the averages, etc. You are asking for specifics about something I wrote decades ago and which, not being trained to program, I figured out the hard way, with no reason to need to remember later once better computers - and programs - came out. At that point instead of programming from scratch, I was figured out ways to make spreadsheets do what I wanted instead.
I'm not asking about how you calculated averages or any specific code. In fact, I don't care for any of that. I'm simply asking how you added two numbers (or subtract two numbers if that's easier) in binary, then displayed them in decimal. You make it seem like it just happened, out of the blue. That's because you don't know what's entailed in your flippant statements. I wouldn't bother asking if you did all that in BASIC, where simple arithmetic is built-in.
But you make it a point you did that in machine language... not even in Assembly, but in machine language. You proudly say so in your WTF bio. You brag about it several times. If it's that important to you, why can't you remember how you did it?
> But you mention you had 16K, which makes me wonder where in the world you hid your machine language code? Don't know. I know there were memory locations which revealed where a program would start in memory, another for where data started. Don't know if the machine code was stored in with Basic or if there was another setting in memory that stored where that was. For example, maybe the computer stored things in three sets - Basic, MC, Data. But I sure don't remember now!
In the 6502 (and in virtually all 8-bit processors), the program counter for BASIC and machine language code runs counter to each other. Again, this wouldn't matter if you wrote in just BASIC or machine language codes, but you say you used both. Even on a maxed out Apple II+ with 48K + 16K had to use what is called bank switching to fit the hungry Applesoft and make room for BASIC programs.
You say your system had 16k only, along with BASIC (assuming MS Basic, since it had peek and poke) would most certainly have required you to use some memory area allocated by/for ROM, screen, graphics, devices, or something. Otherwise, there's no way you could juggle all the data, BASIC program and machine language program within 16K. At the very least, this would have caused you great deal of pain when they all clashed, created glitches. I don't know if you even realize how small 16K is.
You asked what I did and I answered as best I could decades after the fact! And yes, I am proud of what I did. So?
You bragged about it first, and when someone questioned you, you attacked. It was at this point I asked for some proof (why does that patter sound so familiar???).
And for all my questions that arose after all your bragging and attacking, I really got nothing:
Anything specific you don't remember
What system you used, you won't say
What BASIC version you used, you won't say
What CPU? Not the 6502
How did you do any of the calculations? It just happened, pressed a button and off it went?
How did you display the numbers? Using print or something
How did you enter machine code? by hand and by using an app?
What app? don't remember
How did you manage memory for your program? Don't remember
It used less memory, but don't remember how
It ran faster than others, but don't remember how
Copied some code from back of a database manual. don't remember
It didn't page any data to disk, since I only used cassettes. But again, don't remember
If there's this amount of uncertainty, it's only certain it DIDN'T happen.
Same thing with Waytool's "Yes" -- if there's that much uncertainty (as you and Waytools piled on during ~50 posts) it's certainly a "No".
Oh well, as you effectively state, Waytools is extremely consistent in being inconsistent with their update timeframes, so it we take their consistent inconsistency into account, we should get the May 31 update sometime in the weeks before June 30, although as June 30 ends on a Sunday, it may well be the case that the update timeframe
I separate these delays into two categories. One is those they don't come close to. Which would pretty much apply to all those for some months back. Then there are ones that might happen with this one (because it ends on a Friday). Oh, it's still late if they do those things I mentioned and don't post until the following Tuesday night. But while I think they should definitely not wait like that, even if they post part of an update earlier and complete it a few days later (which is fine), a delay of a few days isn't that big of a deal.
To me it should be avoided more because of optics - which means the past record. But, we'll see. Everyone knows the opinions of everyone else by now!
> The line about 'peeks and pokes to save and load' seems like nonsense on the surface, but could be he is remembering inaccurately or mixing some things together. The purpose of peek and poke generally was to store values in registers
Ah, that sounds like the right word, "registers". BTW, did you know it is perfectly possible to write a program without always knowing all the "proper" terminology" - especially decades later?
Of course. All programmers I know started writing programs in their teens -- you know, when they know nothing, but think they know everything. I wanted to be an astronomer when I first started learning C. Not only did I not know all the jargons, I didn't even speak English. How lacking in proper terminology can one be? However, even after decades, I still remember all the struggles and successes I had while writing some things I fawn over half as much as you do your BASIC/machine language hybrid. If you don't remember them (even if not exactly), you're not learning.
There were some that the computer automatically filled in, though you could force changes with a poke. So, for example, one said where the end of a basic program was - it would, of course, be changed every time you changed the size of the program (I do not know if the end of the basic section also included the MC or if that was a separate number). Another said where the Basic program began. I believe another was where the data ended ("ramtop"?). Anyway the computer also kept track of where the app started and, normally, would save everything starting with the basic program and all through the data section. Which wasted time when using a cassette. So I simply peeked into the register that said where the basic program ended and where the data ended, then poked those values into the places so the computer thought it should only start the save at the address where the data was. Of course, I had stuff that saved the original values and put them back when the save was done!
Read my reply to you above. They're called "PC" registers. There's an artificial one for BASIC and innate one for ML (machine language). They run counter. However, you'd have to raid such registers, along with Index registers and other reserved registers to do the type of calculations in the manner you implied in your posts. Meaning both your BASIC program and ML code would be tossed into limbo while just doing simple additions (again, in the manner you implied). This also means you'd have had to allocate a healthy amount of temporary use memory to save and restore your registers.
So your 16K would have had to hold: temp space, ML code, ML data, BASIC program and BASIC's data On top of the usual ROM's space, graphics, screen, device i/o, BASIC interpreter -- all in 16K!
> The last interpretation I can think of is a slight variation of what I just said, which is where he could be slightly misremembering or mis-stating what he did. If you stored data as binary values in registers, which he claims he was doing....
No, I don't think I was claiming that, unless there is some confusion over terminology. My data wasn't peeked or poked. It was all stored in one long string, which was set up when the user first set up their classes. I believe I named it "D$", but I may be wrong. But it was just one long string.
D$ standing for data? Makes sense. Actually, this is the most sense I've seen. That all data was stored, calculated, revised and displayed in BASIC. It's just the ML coding parts that I can't figure out - from what you tell me, at least.
> What is relevant here is that Kahuna clearly has no idea how a modern development team manages architecting modern software
Well, there is that detail that I was writing on my own! So a team of ONE.
Well, even a team of ONE still needs a plan, or at least a few algorithms, one of which could have survived memory?
> thus his rambling opinions on the notions of Waytools 'freeing up space in firmware' and so forth are just nonsense.
Well, maybe you can explain what is nonsense about it? Or is one of the things experts do is fail to explain things? Well, maybe you can explain what is nonsense about it? Or is one of the things experts do is fail to explain things?
I noticed that your SH** list contains 'experts', 'critics'. Are you going to add 'programmers' to that list? You do know that they're not negative?
I don't think I need to be an expert in how teams work together to figure out that if your available memory is full, it makes it much harder to fix problems!
If they're clearing out memory only to fill it back with things like 'sticky keys' and to increase JUMP slots from 6 to 12, it could be a problem, as they're just wasting time. If they're storing numbers like you did with your ML code (storing each digit in ASCII form), that right there went from 1 byte to 2 bytes. There's a theory that says it takes 2 days to clean out things, but less than a day to fill it back up.
> You make it seem like it just happened, out of the blue. Not remembering how I did something well over 3 decades ago isn't doing something "out of the blue". I worked hard at it, figuring things out for myself, getting people to tell me how they did stuff and copying what they offered. It was a long process, first doing it in Basic and then replacing the slow parts with MC.
> You proudly say so in your WTF bio. You brag about it several times. If it's that important to you, why can't you remember how you did it? I can't be proud of what I accomplished? Which, btw, isn't the same as bragging. It is certainly important that I did it, but the details really don't matter to me at all now because I'm NOT PROGRAMMING. > would most certainly have required you to use some memory area allocated by/for ROM, screen, graphics, devices, or something. Otherwise, there's no way you could juggle all the data, BASIC program and machine language program within 16K. At the very least, this would have caused you great deal of pain when they all clashed, created glitches. I don't know if you even realize how small 16K is.
Maybe I did. I don't recall - but I don't think that is how I did it. But the fact remains that I achieved the things I said, by using approaches you pooh-poohed. I could store 20 grades in 20 bytes of memory. Even in my larger than normal classes of, say 40 kids. I could store 20 grades each in a total of 800 bytes to cover the entire class. So, even after memory for the program stuff was subtracted from total memory, you could fit a LOT of stuff in the remaining space.
You last sentence reminds me of the old routine that a bumblebee can't fly, but it does because it doesn't know it can't fly. It just does it. Well, of course there are reasons why it can, but the point is, you act like what I did - and used - and was used by others - couldn't happen because you CHOOSE to not believe it. But I actually used it and KNOW it worked. No crashes. No data corruption.
> when someone questioned you, you attacked. But when you asked your questions, I answered as best I could. Did I believe you were sincere? Heck no. But like I've said, I can be nice to anyone even if they are pretending to just have some interest. Because if they are pretending, they'll reveal it soon enough.
Now let's see how you misrepresent what answers I have given. Just some, to save space - and show a clear pattern:
How did you enter machine code? by hand and by using an app?
I told you I used an app. The app simply let you enter the MC hex number or use the assembly code, which I also told you. I did it both ways because some of the instructions were used so much that I found it easier to use the number that, by then, I had memorized. So your "question" is bogus.
It used less memory, but don't remember how
I told you how. I believe I gave 3 major reasons. So why did you fib about this?
It ran faster than others, but don't remember how
Yet I told you many times. Machine code to replace the slower parts of Basic. So you fibbed again.
Copied some code from back of a database manual. don't remember
False. I know exactly what the database was. I don't recall being asked for the name, though maybe I missed it. Even if I had been asked for it, I wouldn't tell you as that would tell you the computer I used and, since I've also said I made and sold and advertised improvements to that database program (which the author adopted, with my permission), it would also make it fairly easy to find out who I am by searching for that program.
> If there's this amount of uncertainty, it's only certain it DIDN'T happen.
Well, considering how many of those I listed above are either false or misleading, your assumptions mean nothing. But they will serve one good purpose. I think others here should post as to whether they think I created the program I said I did. It will help me to know who has integrity and who just wants to make assumptions so they can attack.
I think your call for "proof" is really just a way to find out who I am - since there is no way to present the proof without also revealing my name and where I've lived because it is all on the net and if you find part, you find it all. Considering all the things you listed that were flat out false, I wouldn't trust you or anyone like you with my personal information.
> Meaning both your BASIC program and ML code would be tossed into limbo while just doing simple additions (again, in the manner you implied). This also means you'd have had to allocate a healthy amount of temporary use memory to save and restore your registers.
Well, I guess you are just wrong because I only had to save and restore a couple two-byte registers! Generally that doesn't take much memory!
> So your 16K would have had to hold: temp space, ML code, ML data, BASIC program and BASIC's data On top of the usual ROM's space, graphics, screen, device i/o, BASIC interpreter -- all in 16K!
Almost no "temp space" since it was only a couple register values that needed saving temporarily. MC, sure. ML data, not really. The MC simply operated on the data stored in a string. My Basic program, sure. And the data strings it created, of course. Don't know what memory may have been used by the ROM or screen - that may have even been in separate memory. I probably knew at the time, but not now.
> I noticed that your SH** list contains 'experts', 'critics'. Are you going to add 'programmers' to that list? You do know that they're not negative?
Oh, I have no problem with programmers - just people who act like their knowledge or experience means they just know better than others and claim something couldn't be true simply because they don't see how. I ran into many programmers who acted more like "experts" - that is, using their status to put down others. Like making a big deal about terminology. Some programmers are like that.
I remember when I switched from Apple to a PC. I had long used Appleworks to make a spreadsheet to do my grades. Through a lot of study, I was able to do one thing that the people I knew or heard from online, had not done. It was a hack job, but it worked. So when I switched and now had the far more powerful Excel spreadsheet, I wanted to do the same thing. Over and over people who create spreadsheets for others as part of their job told me it couldn't be done the way I wanted. I had to do things that were NOT what a teacher would want as a solution. It wasn't until I said that it was strange that I could do something with Appleworks, but couldn't do it with Excel, that someone actually took the time to figure it out instead of just telling me it couldn't be done. And, because Excel was far more powerful, the solution was also more straight-forward - and faster. But most important, it gave me the results I wanted in the form a teacher needed them.
> If they're clearing out memory only to fill it back with things like 'sticky keys' and to increase JUMP slots from 6 to 12, it could be a problem, as they're just wasting time.
Which is, of course, a fair point. But it doesn't change the fact that even without adding anything or making room for anything after GR, they still needed space to handle fixes.
> If they're storing numbers like you did with your ML code (storing each digit in ASCII form), that right there went from 1 byte to 2 bytes.
Where the heck did you get that from??? I store any number from 0-255 as ONE bite. I'm not taking each digit and storing it separately. That would be nuts! If a student scored a hundred, it is stored with the ascii character that matches 100. Simple. Big memory savings. I remember at one point thinking about saving as a string "100" (3 bytes). That would still be better than saving as a floating point number, but then I realized, since I didn't use fractions or decimal scores, ascii was much better.
Let's say I have 10 characters for each name. Each kid has 20 grades. So I have the name and all 20 grades saved in just 30 bytes! 30 such kids would only take a total of 900 bytes! Even if I only had 5k of memory for this data, I could have over 5 classes loaded in at the same time! Since most classes don't have that many tests in a grading period and many don't have that many kids, most teachers could store every class they had for a grading period at one time (figuring most don't have more than 6 classes a day) even in what is left for data out of 16k.
Comments
Which part, and how? I'm just curious about the math part. Character output and keyboard input I'm sure were lightning fast (for the day).
That's not really up to the program you wrote. Just depends on how much memory you had (which must have been 48K. I'm assuming you're not referring to storage, which would be negligible if you only had cassette tapes.
What the heck does this mean? Are you talking about your UI? How pretty things are shown on screen? Normally, programmers talk about structures when referring to the data, not how something manifests on screen.
First, it wasn't an Apple, though it was during the Apple II+ period. I just pointed out it was better than Apple programs I had seen (at least that weren't really expensive and thus out of the price range of the typical teacher). At the time, at least where I was, teachers were just starting to get computers for their use, but only a few. And they didn't know what to do with them!
If I gave the BASIC name (or the computer name) it could narrow things down too much. I was not writing on the typical computers people thought of at the time. I didn't get an Apple until the Apple IIgs, long afterwards. BTW, this was also where I learned it wasn't how popular a computer was that mattered the most when it came to good software. It also wasn't how powerful it was either. It was the programming.
My math was done by MC routines. At the touch of a key you could get the averages of each student in a class either with every grade counting the same or using the weighted grades if you created those. I do not recall the details now, but it seemed like a simple enough matter at the time to calculate the grades either way. Certainly no errors ever showed up when I finished. The MC also printed most of the stuff to the screen (with BASIC back then, you could see the lines being drawn one by one when you had a lot of data to display, especially if there were calculations going on at the same time).
Machine code was entered via another app. It was actually highly praised as letting people enter either the actual hex numbers for the code, or the code itself (like "Ld A" or something like that). You could do code breaks, see how data would change as it went through, etc. I read other people, using popular computers, saying they wish they had something like it. Just one of those labors of love someone took the time to make. Don't recall the name, but I sometimes coded using the hex value and other times the other way on the same app.
There was a little peek and poke with my program, but as I recall, this was only for saving and loading. Since it used a cassette, normally an save operation would save the entire program plus data. Very time-consuming. So I came up with the trick of fooling the computer into thinking the program started where, in actuality, the data started so only that was saved (unless you wanted to save both together - that was a choice). When loading back in, it would just have to load the new data to replace whatever class you had finished (and saved).
Debugging was initially done with the app, then through actual use.
The BASIC program would provide my menus - hit a key to show a particular class, or an individual student, etc, and it would call a MC routine to calculate and show the information.
No idea, at this point, what memory area the MC occupied.
I didn't do decimals or fractions, which was probably the only limitation compared to the typical programs like mine back then (actually, most didn't do fractions). Grades were whole numbers and could be from zero to 254 as I recall, though, obviously few would need that! But it was just as easy to go to that as to go to 100 and it allowed for flexibility - and certainly for ordinary extra credit on a test.
I approached the project simply enough. I didn't like any of the grade book apps I found so I decided to write my own. Interestingly, I learned most of stuff I needed from a database program I had bought which was quite clever - and in the manual, he included the parts of program that were in BASIC as well as the part that were written in MC. So a lot of stuff he needed to do were things I needed to do. So I copied and adjusted as needed. For other things unique to my program, I read and asked questions, solving one thing at a time. My program started in all BASIC and then I converted as I learned how to do things.
Mine was faster than others mostly because of the MC. Most programs of this type weren't doing that. Well, unless you wanted to spend a LOT of money.
The program did hold more data because of the program, not available memory - and my first version only had 16k available. And I'm not counting what you could pull in off a floppy disk or something - just what could be held in memory at one time.
Let me see what I can recall, starting with the programs I found for sale that were not super expensive (though they might cost as much as $40-50 which, after adjusting for inflation, would be a lot more today!
The ones I recall seeing topped out at 40 kids in a class (mine allowed 46 - because that's all I could show on one screen with the display at the time).
The others topped out at 30 grades/student - which is great, but mine topped at at 66, because combined with their name, that was all I could show on one screen, with their average grade.
Now, you couldn't maximize these numbers - more students meant fewer grades for each when dealing with just 16k, but here is an idea of the range in that limited space:
You could have a total of 279 students (divided into different classes since only 46 could be in one class) and each could receive 5 grades. Not much, but for some teachers, that's enough. And not many teachers have that many students anyway. But take the number of students down to 46 and you can give each of them 66 grades.
Most programs had you load one class in at a time from the floppy disk. That wasn't practical with a cassette system. So I allowed them to load a bunch of classes at once (note the example of 279 students - which would require at least 7 classes). All loaded at once. In my own work, I may have 6 classes with a total of 180 kids.
Which brings me to the way I saved memory. Other apps stored grades as floating point numbers. But, if I recall correctly, that took 5 bytes. I stored grades as one of the 256 code values for 8-bit machines - taking just 1 byte. I also saved smaller amounts by using variables in the BASIC section. If I saw a bunch of things like. "Goto 10", I'd set up something like, "Let A = 10". Then everything else would be "Goto A". One byte, verses the 5 for the number 10 being floating point and that number would also take two bytes for each digit - so I saved 6 bytes each time.
As for the structure on the screen, the problem with other apps is that they didn't consider what teachers wanted to see - all at once. At the time, teachers were mostly using paper grade books, but there was one really good thing about them - you could see a LOT all at one time. Usually all the kids in a class and you could go across the row and see all their grades. None of the apps I saw did this. For example, an Apple app I tried only showed 7 students at a time! And, at most, maybe 12 grades for each (I'm pretty sure it was much less than that). So lots of scrolling, both horizontal and vertical to see what I could see all at once on a paper grade book! That gets annoying fast!
With mine, you could see all 46 kids in a class at once with either their average or the results of any one test. Or you could bring up any one student with every test and their average.
Same basic approach, but he had a richer clientele!
DBK would probably note that there’s half a month to go, and he’ll rightly note the end of the month will depend on whether you count time via GMT, UTC, Pacific Time etc.
As a former customer who, despite all, still wants a small keyboard, I hope the news is good, clear, definitive and useful.
We shall see whether it is so, for quality is the primary concern of Waytools etc etc etc etc and we wouldn’t have it any other way given the focus on quality is more important than complaints etc etc (insert more MK-style language here).
May info day be a May day to remember!
If you can't even reveal that, then what year (approximately) did you write your machine code? If cassette tape was in usage at the time, that's a short window. They were temporary measure for the home market in late, late 70s before displaced by floppy in very early 80s. So that windows must have been around 1979-1980.
Peeks and pokes are ways to read and write value to memory. How in God's name did you use them to initiate a routine to record things and save? No wonder it was time consuming. You can peek and poke every memory address, it will not do anything except crash your computer.
As far as cassettes are concerned. Did you use parity and/or error checking? If so, it must have increased the size of your program and data by three-fold (or more). If not, reading and writing anything must have been horrendously unreliable.
Forgive my ignorance, but what is 'MC'? Is this short for machine code? If by 'MC routines' you mean 'machine code routines', yes, that's what I'd like to talk about. You seem to make only a passing reference to it, abbreviating it even. But it's that very 'MC routines' -- the math routines that had stumped Wozniak, Jobs, engineers at Apple for years before Bill Gates dedicated a team to write that and finish out the full BASIC that became Applesoft. Another great milestone for Apple II was Visicalc, which is, if you think about it, nothing more than large math
package that happens to display interesting things if you enter some numbers.
You seem to make light of your achievement. If you had created a specialized math 'routines' (however simple and what CPU it was for -- if it was an 8-bit CPU used around the same era as the 6502), I'd love to know about it.
Any math, precision or otherwise, floating point or otherwise were difficult to do on Apple II. Those 8-bit CPUs, the 6502 or others of its era, can only do two arithmetic ops -- adding and subtracting. Specifically, increment (adding 1) or decrement (subtracting 1). Anything more complicated than this, like 11 + 17 for example, would require you to write some custom math functions. Even starting with a non-zero number, like 10, would mean taking an empty register and incrementing it one by one until you got to 10, and storing that somewhere. Division is traditionally done by continually subtracting 2 until remainder is < 2. Multiplication the other way. Each method takes up valuable cycles. These days with 5Ghz cpus common, cycles are cheap. But in those days, they were precious.
The crude methods are stable, but too slow to be practical. Or you can go all out with bit-flipping trickery like Bill Atkinson when he wrote QuickDraw, but that requires you to be at the top of your boolean math game. You're not Atkinson, Kahuna. But that's okay... no one is. Thus most methods are somewhere in between -- it has to be. I want to know to which side your 'MC routines' lean.
You don't understand the meaning of decimals, which means power of 10, versus binary which is power of 2. So, you didn't do floating point, just whole numbers. You only used 0-254 -- which are decimals, by the way. Why 0-254, not 0-255? Did you do negative numbers? One byte numbers doing both positive and negative will limit you to -127 -> +127. My first primary question is: How did you display those numbers?
You make it seem like if you just throw 0xff (hex) into the display memory, it automagically appears as 255 (decimal). How did you convert the binary hex into decimal number, and vice versa? How did you add these binary numbers, subtract them, multiply them, divide them. And how did you store them, convert them to decimal, and display them?
Again, the CPU don't know how to do any of that. None of that automatically happens. All has to be meticulously programmed. I just want to know how you programmed all that. You don't need to show me any source code. I can fill in the opcodes if you can provide me a concise description, maybe even a loose description.
In the case of Apple II, the ROM reserves a chunk of memory for devices, lo-re and hi-res graphics, BASIC reservers a big chunk for runtime. You would have had to divide userland memory into two parts: for your BASIC program and machine language code. After all that, there's really only a few places where you can safely store anything without clobbering everything, even with the maximum 48K.
But you mention you had 16K, which makes me wonder where in the world you hid your machine language code?
I'll stop here. There's just too much that says nothing but raise more questions than answering anything, even after sifting through all the self-congratulatory comments which are moot since he won't reveal any detail of the system.
Kahuna, your babbling post tells me (and any programmer out there) that you have no idea what you're talking about. Not only can you not tell me anything about your math 'routines', it's obvious you don't even know some of the basic programming terms, yet you throw them about so freely in wrong contexts. You don't seem to know the difference between machine language coding vs assembly. No one in all my years has developed machine code using manual input, peek and poke and assembly -- and I'm sure you don't even know why.
If there is a morsel of truth in what Kahuna posted, any programmer out there please tell me, because I certainly can't find it.
Perhaps that was during the first year when I was still a customer, maybe you've given up trying to rationalise when a time period does or doesn't end, and whether or not Waytools should or shouldn't have given an update during the often vague timeframe in which they loosely specify without any spot-on specifics when they will or won't be coming forth and be forthcoming with an update (or not).
Or something like that. Comms from Waytools get blurry in the memory, they're so similar and dissimilar at the same time, it's kind of like a best of times and worst of times situation blended together in one big nothing burger of McDonalds, Wendys, Burger King and Five Guys at the same time, yet from a multitude of multiverses all at the same time.
We await Waytools weighing in without waywardness and with a great weight of clarity, which will be a first.
Whenever that may be - Californian time will be just fine. Half a month to go before May ends.
There are a couple morsels.
I used cassettes for storage up until about 1983. Parity? I cant recall. If there was any parity it would presumably have been part of the chipset that interfaced with the tape drive. The Commodore cassette drive moved data at about 400bps - not Kbps, not Mbps, not Gbps...just plain old bps
The line about 'peeks and pokes to save and load' seems like nonsense on the surface, but could be he is remembering inaccurately or mixing some things together. The purpose of peek and poke generally was to store values in registers, which were typically used to store executable instructions, data values, or to define a behavior of the machine which was set by constantly polling the various registers.
Perhaps whatever computer he was using (I too question the validity of concealing the make of the computer, as if anyone could ID a person by that fact) had a register which could be poked to indicate 'start read from tape' or 'start write to tape', although most systems had BASIC commands to accomplish that, ie, LOAD"*",8,1 to get the directory from a 1541 disk drive, so that seems like a poor interpretation.
The other way to interpret 'peeks and pokes to save and load' would be to infer he had written a BASIC bootstrap routine that poked all the machine code values comprising a load/save machine language subroutine from a DATA array into memory and then executed the machine code via an MS BASIC style 'SYS' command, ie, SYS49152, which would tell the CPU to execute a machine language subroutine starting at address 49152. But that seems totally unnecessary. Every machine that had Microsoft BASIC on it had load/save commands to do all that hard work for the user. And I do not detect in Kahuna the skillz to write any machine language subroutine from scratch so it must have been someone elses code (there was plenty available in magazines at the time).
The last interpretation I can think of is a slight variation of what I just said, which is where he could be slightly misremembering or mis-stating what he did. If you stored data as binary values in registers, which he claims he was doing, then you might want to write those registers out to tape or disk, so you might set up a loop in BASIC to PEEK through all the memory addresses to obtain the values and then write them as a 'file' (in the loosest sense of that word - a data stream with some bytes to indicate end of stream) to tape or disk. This kind of task was fairly common and trivial, so I could envision him having written a simple BASIC program where he poked some data into a sequence of memory addresses, and then peeked through those addresses to store the data on tape.
As far as the binary math and related business logic issues, I totally agree, that is non-trivial for anyone operating at the level of a BASIC programmer, and given the amount of memory that the business logic would use to implement conversions and manipulation of values and so forth, it would probably be pointless to implement that way, though I could imagine a guy who is teaching himself BASIC programming doing it just for the exercise.
So overall, I am skeptical of his memory of what he actually implemented vs what someone else might have implemented which he merely used. I detect a slight amount of self-aggrandizing. lolz
None of which matters. What is relevant here is that Kahuna clearly has no idea how a modern development team manages architecting modern software, thus his rambling opinions on the notions of Waytools 'freeing up space in firmware' and so forth are just nonsense. Among the top ten most annoying things about Kahuna, surely a contender for the #1 position would be how rigorously he will assert an opinion about a subject which he clearly knows nothing about.
> Peeks and pokes are ways to read and write value to memory. How in God's name did you use them to initiate a routine to record things and save? No wonder it was time consuming. You can peek and poke every memory address, it will not do anything except crash your computer.
Well, it didn't crash the computer so I guess what I did worked. The peeks and pokes simply let me see where the data started, then I could poke that into the place that stored where to start saving. It was just like two spots. No big deal. Anytime I loaded a saved data section in, it put the proper numbers back in. Thus the built-in save routine only saved what I wanted, rather than the whole program every time. Too long ago now to get more specific than that, but it worked - and worked every time.
> reading and writing anything must have been horrendously unreliable.
The only reliability issue would be the tape itself. These were just ordinary cassettes and anyone using this kind of system knew it was always a good idea to make more than one copy in case the tape had a bad spot in it.
> Forgive my ignorance, but what is 'MC'? Is this short for machine code?
Yep.
> You seem to make light of your achievement. If you had created a specialized math 'routines' (however simple and what CPU it was for -- if it was an 8-bit CPU used around the same era as the 6502), I'd love to know about it.
It was 8-bit. I make light of it because it didn't seem like a big deal to me. And I know it worked. Maybe the computer did some stuff I wasn't aware of. Maybe I'm taking a simpler approach than you are imagining. At this point, I have no idea what the code actually was or the Basic part either! But it worked.
> You're not Atkinson, Kahuna. But that's okay... no one is. Thus most methods are somewhere in between -- it has to be. I want to know to which side your 'MC routines' lean.
Sorry, but I'm not going to remember much from nearly 40 years ago! And, as I said, I wasn't a trained programmer. I simply found things I wanted to do and methodically found answers for how to do them, copying things I was pointed to. Not doing it full time so not likely to retain the details so many years later! I'm not even going to remember the basic steps for a lot of it.
> You don't understand the meaning of decimals, which means power of 10, versus binary which is power of 2.
I'm a teacher, so when I refer to decimals and fractions, I'm not talking about the computer stuff, but whether a teacher can give only whole number scores (1, 2, 3, etc) or decimal/fraction scores (95.3 or 95-1/2). My program didn't allow either. Most teachers don't use them, but some do. So that was a limitation if a teacher used my program and wanted to include those.
>Why 0-254, not 0-255?
Because 255 was reserved for something else. Specifically "NG" (for no grade). This gave the teacher an option when entering scores when someone didn't take the test. In some cases, they may be excused so you don't want it averaged in at all (thus NG). In other cases a student who misses a test may be given a zero by the teacher so they could do that if they wished. Like I said, I was a teacher and knew the kinds of things they wanted. You'd be surprised at how many similar programs didn't allow for that.
No negative scores. There may be tests where that is necessary, but I've never run into them so, if some teacher needed that, that would be another limitation of my program - a small one.
> How did you display those numbers?
As numbers: 99, 100, 96, whatever.
> How did you convert the binary hex into decimal number, and vice versa?
Don't recall the code to do it, but in basic, I think it would have been something like, "Print Code "D". Or maybe it was Val Code "D". Too long ago to recall. When a teacher entered a grade (in Basic because speed was not an issue for that), if they entered "100", it was stored as whatever character in the ascii set that was 100.
I certainly don't recall the code process for getting the averages, etc. You are asking for specifics about something I wrote decades ago and which, not being trained to program, I figured out the hard way, with no reason to need to remember later once better computers - and programs - came out. At that point instead of programming from scratch, I was figured out ways to make spreadsheets do what I wanted instead.
> But you mention you had 16K, which makes me wonder where in the world you hid your machine language code?
Don't know. I know there were memory locations which revealed where a program would start in memory, another for where data started. Don't know if the machine code was stored in with Basic or if there was another setting in memory that stored where that was. For example, maybe the computer stored things in three sets - Basic, MC, Data. But I sure don't remember now!
> even after sifting through all the self-congratulatory comments which are moot since he won't reveal any detail of the system.
??? A little ways back you were saying I made light of some big accomplishment!
You asked what I did and I answered as best I could decades after the fact! And yes, I am proud of what I did. So?
As for the system, I'll just add that it was not a 6502.
And now we get to what I think was the purpose of your original questions - which wasn't to really learn how I did things:
> Kahuna, your babbling post tells me (and any programmer out there) that you have no idea what you're talking about.
Yet the program worked.
> Not only can you not tell me anything about your math 'routines'
Right, decades later I can't recall.
> it's obvious you don't even know some of the basic programming terms
Maybe because I wasn't trained as a programmer? Just a hunch. But I see snobbism rearing it's head!
> If there is a morsel of truth in what Kahuna posted, any programmer out there please tell me, because I certainly can't find it.
Ah, and now the insinuation that what I said isn't "truth"?
But, typical of those times I did point out reasonable possibilities, it was because they were reasonable, such as saying "end of the week" could be taken as meaning Friday, Saturday, or Sunday. Thus not fair to criticize them for not giving an update for "next week" when we have only reached Tuesday or Wednesday of that week! It was posts like that I was responding to.
But I'll give you some bad news about May 31st. It's a Friday. And, yes, it the update doesn't come until after the first few hours of Saturday (say 3:00 AM) - because even though it is Saturday, it would also be part of Mark's Friday workday - if it takes that long, I would not be surprised if they waited until Tuesday. No, I'm not saying that is okay. I'm saying what won't surprise me. The reason would be that, at least in the past, they had tests running which they would go over at a weekly Monday meeting where they make decisions. Then to get a big update out may take into the next day.
I really think they should avoid that. But it isn't my main worry. That would be the fact that they have already missed a BUNCH of updates since the last one so until I see it, I'll be worried that it won't happen. And yes, WT knows how I feel about that!
Ah, that sounds like the right word, "registers". BTW, did you know it is perfectly possible to write a program without always knowing all the "proper" terminology" - especially decades later?
There were some that the computer automatically filled in, though you could force changes with a poke. So, for example, one said where the end of a basic program was - it would, of course, be changed every time you changed the size of the program (I do not know if the end of the basic section also included the MC or if that was a separate number). Another said where the Basic program began. I believe another was where the data ended ("ramtop"?). Anyway the computer also kept track of where the app started and, normally, would save everything starting with the basic program and all through the data section. Which wasted time when using a cassette. So I simply peeked into the register that said where the basic program ended and where the data ended, then poked those values into the places so the computer thought it should only start the save at the address where the data was. Of course, I had stuff that saved the original values and put them back when the save was done!
>The other way to interpret 'peeks and pokes to save and load' would be to infer he had written a BASIC bootstrap routine that poked all the machine code values comprising a load/save machine language subroutine from a DATA array....
Nope. As I said, this was a very tiny bit of peeking and poking of specific registers to control what was saved. Once that was done, I just activated the standard Save command.
> The last interpretation I can think of is a slight variation of what I just said, which is where he could be slightly misremembering or mis-stating what he did. If you stored data as binary values in registers, which he claims he was doing....
No, I don't think I was claiming that, unless there is some confusion over terminology. My data wasn't peeked or poked. It was all stored in one long string, which was set up when the user first set up their classes. I believe I named it "D$", but I may be wrong. But it was just one long string.
> What is relevant here is that Kahuna clearly has no idea how a modern development team manages architecting modern software
Well, there is that detail that I was writing on my own! So a team of ONE.
> thus his rambling opinions on the notions of Waytools 'freeing up space in firmware' and so forth are just nonsense.
Well, maybe you can explain what is nonsense about it? Or is one of the things experts do is fail to explain things?
I don't think I need to be an expert in how teams work together to figure out that if your available memory is full, it makes it much harder to fix problems!
All of that said, we might get an update on Thursday, May 30, which will avoid the whole May 31 situation which stretches Mark's workday into Saturday at 3am, but given the next update is only one update of the presumably many needed before GR generally becomes the general release date, we catapult ourselves back into the timeframes above, all of which end their monthly timeframes either on a week day or weekend, all of which might mean stretching either to the end of the week (and thus a new month), or ending on a weekend, which would by necessity of weekends generally only being times during which work may or may not cease, thus pushing things into a new week, that we might, or might not reasonably (or otherwise) expect a universe of possibilities to indicate virtually any timeframe, because it is reasonable to note that the "end of the week" could be taken as meaning Friday, Saturday or Sunday, or if Mark's Sunday weekend workday stretches into 3am Monday, I would not be surprised if a delay was delayed until Tuesday, which could stretch to Wednesday, or Thursday, or Friday, or Saturday, or even Sunday, which, if Mark's Sunday weekend workday stretches into 3am Monday, I would not be surprised if a delay was delayed until Tuesday, which could, you know, stretch to Wednesday, or Thursday, or Friday, or Saturday, or even Sunday.
As the Cylons said, all of this has happened before and will happen again. It's the great cycle. Game of Thrones wishes not to stop the wheel, but to break it (which we might see next episode in the series finale), but of course, if we break it (like a TREG test unit TextBlade playing up in some way), this will start the cycle all over again, and that's how we get to the year 2022 and Catch 2022!
But... I'm repeating myself, like a delete key that keeps on deleting until everything is deleted.
Cheers to all,
Alex.
I figured you might take that question completely out of context. Most people would read and understand the context of the question. I even explained this context before and after the question. But along with this:
It tells me you stored numbers (e.g. 100) in ASCII format, which means a value of 100 which can be stored as one byte in the form 0x64 was instead used three bytes (ASCII for '1', ASCII for '0', ASCII for '0') + END_MARKER for a total of four bytes. In short, you stored an integer number value (100) as a string ("100").
Not only is this the worst way of wasting memory, it still doesn't explain how you did any calculations. It would mean that you'd have to:
everytime you want to add two numbers. For sake of brevity, I didn't bother noting how many valuable cycles each line would waste. So, waste of memory and waste of cycles... it's a wonder anything ran at all.
I'm not asking about how you calculated averages or any specific code. In fact, I don't care for any of that. I'm simply asking how you added two numbers (or subtract two numbers if that's easier) in binary, then displayed them in decimal. You make it seem like it just happened, out of the blue. That's because you don't know what's entailed in your flippant statements. I wouldn't bother asking if you did all that in BASIC, where simple arithmetic is built-in.
But you make it a point you did that in machine language... not even in Assembly, but in machine language. You proudly say so in your WTF bio. You brag about it several times. If it's that important to you, why can't you remember how you did it?
In the 6502 (and in virtually all 8-bit processors), the program counter for BASIC and machine language code runs counter to each other. Again, this wouldn't matter if you wrote in just BASIC or machine language codes, but you say you used both. Even on a maxed out Apple II+ with 48K + 16K had to use what is called bank switching to fit the hungry Applesoft and make room for BASIC programs.
You say your system had 16k only, along with BASIC (assuming MS Basic, since it had peek and poke) would most certainly have required you to use some memory area allocated by/for ROM, screen, graphics, devices, or something. Otherwise, there's no way you could juggle all the data, BASIC program and machine language program within 16K. At the very least, this would have caused you great deal of pain when they all clashed, created glitches. I don't know if you even realize how small 16K is.
You bragged about it first, and when someone questioned you, you attacked. It was at this point I asked for some proof (why does that patter sound so familiar???).
And for all my questions that arose after all your bragging and attacking, I really got nothing:
If there's this amount of uncertainty, it's only certain it DIDN'T happen.
Same thing with Waytool's "Yes" -- if there's that much uncertainty (as you and Waytools piled on during ~50 posts) it's certainly a "No".
To me it should be avoided more because of optics - which means the past record. But, we'll see. Everyone knows the opinions of everyone else by now!
Of course. All programmers I know started writing programs in their teens -- you know, when they know nothing, but think they know everything. I wanted to be an astronomer when I first started learning C. Not only did I not know all the jargons, I didn't even speak English. How lacking in proper terminology can one be? However, even after decades, I still remember all the struggles and successes I had while writing some things I fawn over half as much as you do your BASIC/machine language hybrid. If you don't remember them (even if not exactly), you're not learning.
Read my reply to you above. They're called "PC" registers. There's an artificial one for BASIC and innate one for ML (machine language). They run counter. However, you'd have to raid such registers, along with Index registers and other reserved registers to do the type of calculations in the manner you implied in your posts. Meaning both your BASIC program and ML code would be tossed into limbo while just doing simple additions (again, in the manner you implied). This also means you'd have had to allocate a healthy amount of temporary use memory to save and restore your registers.
So your 16K would have had to hold: temp space, ML code, ML data, BASIC program and BASIC's data
On top of the usual ROM's space, graphics, screen, device i/o, BASIC interpreter -- all in 16K!
D$ standing for data? Makes sense. Actually, this is the most sense I've seen. That all data was stored, calculated, revised and displayed in BASIC. It's just the ML coding parts that I can't figure out - from what you tell me, at least.
Well, even a team of ONE still needs a plan, or at least a few algorithms, one of which could have survived memory?
I noticed that your SH** list contains 'experts', 'critics'. Are you going to add 'programmers' to that list? You do know that they're not negative?
If they're clearing out memory only to fill it back with things like 'sticky keys' and to increase JUMP slots from 6 to 12, it could be a problem, as they're just wasting time. If they're storing numbers like you did with your ML code (storing each digit in ASCII form), that right there went from 1 byte to 2 bytes. There's a theory that says it takes 2 days to clean out things, but less than a day to fill it back up.
Yet it worked great. Whether you "wonder" or not.
> You make it seem like it just happened, out of the blue.
Not remembering how I did something well over 3 decades ago isn't doing something "out of the blue". I worked hard at it, figuring things out for myself, getting people to tell me how they did stuff and copying what they offered. It was a long process, first doing it in Basic and then replacing the slow parts with MC.
> You proudly say so in your WTF bio. You brag about it several times. If it's that important to you, why can't you remember how you did it?
I can't be proud of what I accomplished? Which, btw, isn't the same as bragging. It is certainly important that I did it, but the details really don't matter to me at all now because I'm NOT PROGRAMMING.
> would most certainly have required you to use some memory area allocated by/for ROM, screen, graphics, devices, or something. Otherwise, there's no way you could juggle all the data, BASIC program and machine language program within 16K. At the very least, this would have caused you great deal of pain when they all clashed, created glitches. I don't know if you even realize how small 16K is.
Maybe I did. I don't recall - but I don't think that is how I did it. But the fact remains that I achieved the things I said, by using approaches you pooh-poohed. I could store 20 grades in 20 bytes of memory. Even in my larger than normal classes of, say 40 kids. I could store 20 grades each in a total of 800 bytes to cover the entire class. So, even after memory for the program stuff was subtracted from total memory, you could fit a LOT of stuff in the remaining space.
You last sentence reminds me of the old routine that a bumblebee can't fly, but it does because it doesn't know it can't fly. It just does it. Well, of course there are reasons why it can, but the point is, you act like what I did - and used - and was used by others - couldn't happen because you CHOOSE to not believe it. But I actually used it and KNOW it worked. No crashes. No data corruption.
> when someone questioned you, you attacked.
But when you asked your questions, I answered as best I could. Did I believe you were sincere? Heck no. But like I've said, I can be nice to anyone even if they are pretending to just have some interest. Because if they are pretending, they'll reveal it soon enough.
Now let's see how you misrepresent what answers I have given. Just some, to save space - and show a clear pattern:
- How did you enter machine code? by hand and by using an app?
I told you I used an app. The app simply let you enter the MC hex number or use the assembly code, which I also told you. I did it both ways because some of the instructions were used so much that I found it easier to use the number that, by then, I had memorized. So your "question" is bogus.- It used less memory, but don't remember how
I told you how. I believe I gave 3 major reasons. So why did you fib about this?- It ran faster than others, but don't remember how
Yet I told you many times. Machine code to replace the slower parts of Basic. So you fibbed again.- Copied some code from back of a database manual. don't remember
False. I know exactly what the database was. I don't recall being asked for the name, though maybe I missed it. Even if I had been asked for it, I wouldn't tell you as that would tell you the computer I used and, since I've also said I made and sold and advertised improvements to that database program (which the author adopted, with my permission), it would also make it fairly easy to find out who I am by searching for that program.> If there's this amount of uncertainty, it's only certain it DIDN'T happen.
Well, considering how many of those I listed above are either false or misleading, your assumptions mean nothing. But they will serve one good purpose. I think others here should post as to whether they think I created the program I said I did. It will help me to know who has integrity and who just wants to make assumptions so they can attack.
I think your call for "proof" is really just a way to find out who I am - since there is no way to present the proof without also revealing my name and where I've lived because it is all on the net and if you find part, you find it all. Considering all the things you listed that were flat out false, I wouldn't trust you or anyone like you with my personal information.
Well, I guess you are just wrong because I only had to save and restore a couple two-byte registers! Generally that doesn't take much memory!
> So your 16K would have had to hold: temp space, ML code, ML data, BASIC program and BASIC's data
On top of the usual ROM's space, graphics, screen, device i/o, BASIC interpreter -- all in 16K!
Almost no "temp space" since it was only a couple register values that needed saving temporarily. MC, sure. ML data, not really. The MC simply operated on the data stored in a string. My Basic program, sure. And the data strings it created, of course. Don't know what memory may have been used by the ROM or screen - that may have even been in separate memory. I probably knew at the time, but not now.
> I noticed that your SH** list contains 'experts', 'critics'. Are you going to add 'programmers' to that list? You do know that they're not negative?
Oh, I have no problem with programmers - just people who act like their knowledge or experience means they just know better than others and claim something couldn't be true simply because they don't see how. I ran into many programmers who acted more like "experts" - that is, using their status to put down others. Like making a big deal about terminology. Some programmers are like that.
I remember when I switched from Apple to a PC. I had long used Appleworks to make a spreadsheet to do my grades. Through a lot of study, I was able to do one thing that the people I knew or heard from online, had not done. It was a hack job, but it worked. So when I switched and now had the far more powerful Excel spreadsheet, I wanted to do the same thing. Over and over people who create spreadsheets for others as part of their job told me it couldn't be done the way I wanted. I had to do things that were NOT what a teacher would want as a solution. It wasn't until I said that it was strange that I could do something with Appleworks, but couldn't do it with Excel, that someone actually took the time to figure it out instead of just telling me it couldn't be done. And, because Excel was far more powerful, the solution was also more straight-forward - and faster. But most important, it gave me the results I wanted in the form a teacher needed them.
> If they're clearing out memory only to fill it back with things like 'sticky keys' and to increase JUMP slots from 6 to 12, it could be a problem, as they're just wasting time.
Which is, of course, a fair point. But it doesn't change the fact that even without adding anything or making room for anything after GR, they still needed space to handle fixes.
> If they're storing numbers like you did with your ML code (storing each digit in ASCII form), that right there went from 1 byte to 2 bytes.
Where the heck did you get that from??? I store any number from 0-255 as ONE bite. I'm not taking each digit and storing it separately. That would be nuts! If a student scored a hundred, it is stored with the ascii character that matches 100. Simple. Big memory savings. I remember at one point thinking about saving as a string "100" (3 bytes). That would still be better than saving as a floating point number, but then I realized, since I didn't use fractions or decimal scores, ascii was much better.
Let's say I have 10 characters for each name. Each kid has 20 grades. So I have the name and all 20 grades saved in just 30 bytes! 30 such kids would only take a total of 900 bytes! Even if I only had 5k of memory for this data, I could have over 5 classes loaded in at the same time! Since most classes don't have that many tests in a grading period and many don't have that many kids, most teachers could store every class they had for a grading period at one time (figuring most don't have more than 6 classes a day) even in what is left for data out of 16k.