|
Post by gsteemso on Apr 19, 2016 13:07:55 GMT
Ah, so you did already know that, that's good. I hope I didn't come across as patronizing, there! You did mention a couple of memory locations which a book claims to be relevant, so I suppose the easiest way forward is as follows:
1) in direct mode, tell BASIC to PRINT a decimal number and manually count how many digits show up after the period. That will give you a baseline: Now you will know approximately what value should already be in the memory location you're looking for.
2) examine each of the candidate locations (whether by PEEK or via the built-in machine language monitor, user's choice), in hopes of seeing either the value determined in step 1 or a number that only differs from it by 1.
3) if you found it, POKE a (smaller!) test value into it and then repeat the PRINT test to verify. If you didn't find it, well, I can think of a few things to try but none of them seem especially likely to work (I am not very experienced at this sort of blind "code archaeology"—much of my relevant knowledge comes from reading about others' successes).
|
|
|
Post by gsteemso on Apr 19, 2016 2:06:05 GMT
I feel you may be labouring under a misconception here. Commodore BASIC does not store numbers in decimal form internally. Any concept of "numbers have x decimal places" inherently applies ONLY to the display of those numbers, not how they are stored or how calculations are performed using them.
That said, in theory you could mutilate the internals of BASIC such that any and all conversions from floating-point to character-string values automatically only show one decimal place. If that possibility was actively allowed for when the ROMs were laid out, it is entirely plausible that the number of digits to place after the decimal point is stored as an ordinarily unchanging, but editable, variable in RAM somewhere; which could easily be altered in that way by a simple POKE command. Is that what you meant?
|
|
|
Post by gsteemso on Apr 11, 2016 6:20:00 GMT
Heh, yeah, getting repeatedly complained at is a strong incentive towards brevity! Um, at least your meaning comes through clearly? (*wince*)
Is the thing with the consolidated drive controller really the only actual design change? I had always picked up a vague impression there was more to it than that, though of course details are rarely alluded to.
|
|
|
Post by gsteemso on Apr 11, 2016 0:45:18 GMT
Most of us know of the differences between a flat 128 and a 128D, which are for the most visible part (1) a detached keyboard and (2) 64K VDC RAM. Quite a few of us, though by no means all, are also vaguely aware that there are some sort of variations among 128D models, though the most that ever gets mentioned casually is that one flavour was North American, the other European… and one is housed in a metal case, the other in plastic. Careful attention to passing mentions will net a novice the further information that one flavour is unofficially called the DCR for "D, cost reduced." I have been aware of these three minor points of distinction for years, though as I have never owned either model of 128D I have never paid enough attention to them to be able to state which fact goes with which 128D revision.
While your post does a concise job of setting out which of the D and DCR is from which continent and which kind of case material each one has, your subsequent reiteration of the point that further differences between the two exist does not answer the question of what any of those other differences actually ARE. Please elaborate! I am very curious about this stuff, especially given that a forum conversation like this is both more interactive and likely to go much more in-depth than looking it up on Wikipedia or some such.
The only further datum I personally can recall on this subject is that the cost-reduced board has a moderately crippled 1571 controller board implementation included right on the main computer board, with a few components consolidated with those of the CPU circuitry and/or eliminated entirely in order to reduce the part count. Alas, the specific changes that were made in that regard are rumoured to impair compatibility with the more esoteric aspects of disk-drive programming, though once again, the nature of any incompatibilities is rarely stated plainly—you are expected to either already know, or have an independent source of hard-to-find information handy.
The following is not in response to any prior post in this thread; I just felt a need to pull up a soapbox for a moment… Please pardon my blabbering.
I'm sure the relevant details (or, at least, most of the better-known ones) of what was changed from the D to the DCR could be figured out soon enough with judicious use of search engines, but we join forums like this one so we can explicitly share knowledge and converse about the parts that may be unclear, not so we can link to some static (and potentially erroneous in subtle ways) document elsewhere, that is most likely going to be perfectly usable in its limited way—until one day you try to refer back to it, but it isn't there anymore.
I'm sure we are all entirely too aware of that particular point after what befell our predecessor forum, "Commodore 128 (and PET) Alive!". Again, none of this little postamble is directed at anyone in particular. I just felt it should be stated explicitly at some point.
|
|
|
Post by gsteemso on Apr 9, 2016 23:47:37 GMT
I think your problem with the theft question is therefore one of definitions.
Companies who ask such screening questions are concerned about DELIBERATE AND SELFISH THEFT, but in considering how to honestly answer, you immediately (and, in my mind, inexplicably) conflated that with ACCIDENTAL ACCUMULATION. The two are not remotely similar.
No one I have ever met, not even the most deranged martinet, would seriously initiate a firing over someone ACCIDENTALLY acquiring items of small value. In that situation, the question of a "second chance" would never arise because no one sane would consider the matter to have used up the first one. Taking a company pen normally falls into this category even if at some level one is nominally aware it is not personally owned by the taker, because it is a consumable supply that the company expects you to use on its behalf until it stops working and chances are it will still be in your pocket when you return to work the next day.
An employee who KNEW they were committing a theft and cheerfully did it anyway, no matter how small the value of what was taken, is a completely different matter. This is the kind of person who makes a habit of stealing as many supplies from their job as they can get away with, and outfits friends, family members, passersby, etc. with them in order to avoid paying a few cents out of pocket to buy their own. Such a person has little or no respect for the concept of ownership save as applies to preventing similar fates from befalling items they themselves possess (and, in many cases, places little weight on other personal boundaries except in their own interest either), and also would probably consider themselves not to have committed an offence worthy of using up that first chance… but a reasonable and law-abiding individual with at least minimal ethics would not agree.
That is the difference.
|
|
|
Post by gsteemso on Apr 8, 2016 6:34:04 GMT
Do you think an employee who stole less than $1 should be given a second chance? (I said yes)
Do you think an employee who stole less than $5 should be given a second chance? (I said yes) Do you think an employee who stole less than $25 should be given a second chance? (I said no)
In other words, if by casual circumstance, an employee "got away" with $5 of money/product, I (as a supervisor) would be considerate.... but if you REALLY look at those questions, I probably should have answered YES to the $25 question? Technically, $1 and $5 are both less than $25! Can you say LOADED QUESTION? Good, I knew you could!
Uh, what? How the heck do you reach a conclusion like that? What those three questions are testing for is the exact opposite of what you concluded with that whole "loaded question" thing. From the company's point of view, this is not rocket science—it's impossible to catch every incident of bad behaviour on the part of a dishonest employee, so if he's found stealing once, there were almost certainly numerous other occasions where he got away with it. The amount that was stolen is irrelevant. There's stuff that is yours and there's stuff that is not, and an employee unable or unwilling to tell them apart is eventually going to rob you blind. A prospective hire who explicitly admits he doesn't consider that a problem worth reporting is essentially admitting he doesn't give a shit about the company he's asking for a job. Would you hire someone with a mindset like that? I can guarantee that you failed this test with that "yes" answer to the first of those three questions, not the "no" to the third. The "no" was the only one of them you got right. That said, I agree with you about the ineptly applied reverse psychology. A correctly designed test would not make the ridiculously amateur mistake of assuming that everyone thinks in a similar way, or suffers from the same mental blind spots. Most of the rest of those, had they been phrased correctly, would not have excluded you from consideration for employment. Look on the bright side… would you really want to suffer working for a bunch of bozos who happily rely upon a barely literate human resources department? I shudder to imagine the dog's breakfast they would make of anything the least bit unusual concerning your pay or benefits (vacation and sick days are a perennial source of such hiccups). The entrance screening to be hired by the day labour agency I used to get jobs through was in this same vein, but much more direct. It asked questions like "When is it OK to smoke pot on a workday?" with four multiple choice answers. In addition to the incredibly obvious answer they were looking for ("never"), the other three were self-evidently silly options such as "only during breaks" and "whenever you feel like it." Astoundingly, people actually managed to fail this question, and others that were just as obvious!
|
|
|
Post by gsteemso on Apr 4, 2016 14:00:24 GMT
Interesting syntax suggestion, though I am not totally sure I would choose that particular keyword pair (admittedly, nothing better immediately suggests itself). The only improvement I can suggest off the top of my head is that vertical pixels per cell can be pretty much any value between 2 and 32 as far as the VDC cares, without the user even needing to fiddle with exact register values to keep their monitor happy.
|
|
|
Post by gsteemso on Mar 31, 2016 17:35:55 GMT
Yes, just like similar cartridges such as RR-net. The reasons people are hoping for a solution that takes a different approach are numerous, though. A cartridge of that nature inherently works only with a C64, or if you are lucky a 128—owners of other machines are out of luck. Also, since it is driven by a software stack running on the actual Commodore, it uses up an unfortunate percentage of limited system resources in order to actually do anything useful. That was part of the reasoning behind hanging the Comet off of user-port RS232 and the flyer off of the same bus that connects disk drives and printers. Not only do they get ANY machine with a suitable port online, they do it transparently! Obviously, constructing low-level network packets will consume some host resources and partially negate the benefits of the "outboard" interface placement, but overall it's still an improvement.
In response to an earlier question in the thread, I believe the Flyer was enhanced to use either or both of JiffyDOS and/or Fast Serial when they are available, but it worked just fine before that too, when it only knew about Slow Serial. It has enough onboard memory to buffer the incoming stream when it needs to, and in any case, TCP was designed from the start to account for similar issues.
|
|
|
Post by gsteemso on Mar 29, 2016 2:49:58 GMT
And, of course, if the total game size absolutely cannot be brought under 32K without ridiculous and show-stopping contortions such as extremely time-consuming heavy-duty compression, it would be inconvenient but hardly prohibitive to bank-switch parts of the cart ROM.
I suspect that technique was only used infrequently when this stuff was current technology because (1) most programs and such back then really were that small by pure economic necessity (if you're coding every few bytes nearly by hand with a primitive 1980s assembler, 32 thousand of them takes a LOT of programmer hours to fill up!), and (2) the paltry few 74xx logic chips required to enable bank-switched ROM access in a cart (and ESPECIALLY the extra cost of assembly!) would have more than eaten through any realistic profit margin for most things short of a killer app... and as I recall, the C128 never really had its own killer app.
|
|
|
Post by gsteemso on Mar 29, 2016 2:03:56 GMT
Very cool! If I had time to rearrange the drifts of stalled repair projects and other junk currently preventing me putting the C128 back where it belongs (I packed it up for a user group meeting a little while ago and haven't gotten around to putting it back), I would try this on my 1902A right here and now. Your approach of trying to fiddle the width before doing anything else makes a lot of sense, but I have to point out-- by backing the display area right up against the horizontal blanking interval like that, you are basically taking the overscan area and declaring that it will contain valid data. The reason there even is an overscan area is that some monitors (including, if I recall correctly, the great majority of CRT monitors) are flatly incapable of cleanly displaying all of it, requiring certain timing cushions surrounding the displayable parts of the signal in order to work stably. It is implicit that there will always be some users who would only be able to view the edges of this mode by getting a different monitor.
I do like the way that, even though the VDC is not really designed to go much above 300 lines per video field without substantial effort being put into tweaking the timings, you get basically double the vertical resolution at no cost beyond a bit of extra flicker just by enabling interlacing. I do wonder how much data (i.e., how many character cells) the VDC can pack into one horizontal row without changing the other timings very much. Pretty sure that's already a known answer limited by the memory bandwidth, but now I am curious. Heh, guess I know what I'll be looking up for the rest of the evening!
|
|