Ok, as airship don't want...
Now my most favorite question:
Why is a C 128 out of the "first batch" basically only a C 119?
WTE
Wild stab at this one... since I couldnt find anything about a C119 commodore computer, my guess is that the first batch didnt actually have a full 128k, maybe due to a bug or something?
Broken MMU chip?
9K? I could see maybe how you could lose 8K, but 9K?!?
I guess because writes to the upper memory (8K) in bank 1 would actually go to bank 0 (bug in the MMU) and because the common ram (1k) could not be disabled (common RAM configuration register not implemented).
All answers wrong!
The "first batch" is related to the first kernal version (official kernal! I'm not talking about any prototypes)
WTE
Hmmm... Where's Bil Herd when you need him? ;)
-Andrew
Original KERNAL? With the Caps-Lock "Q" bug? I have that ROM... now to figure this out...
Im not sure I understand..... who cares about the kernal anyway? :D
The kernal is something, like BASIC, that you switch out at your earliest convenience :)
Quote from: StyleCHM on January 24, 2008, 05:33 PM
Im not sure I understand..... who cares about the kernal anyway? :D
The kernal is something, like BASIC, that you switch out at your earliest convenience :)
You shouldn't do so if you want to win this competition.
Read my question like this:
Why is a C 128 out of the "first batch"
basically only a C 119?
WTE
PS: The capabilities of BASIC 7.0 (compiled!) and the VDC together were the biggest advantages compared to the C64. The most C64 programmers failed to program the C128 (it was to sophisticated for them). >:D
Bil really shouldve gone the whole hog and had 4Mhz ram and 2Mhz VIC-II.
But its a nice machine anyway :D
Now I get it!
The answer is because BASIC reports 122365 bytes free. That equals 119 K (rounded to the nearest K).
But why does it?
Quote from: hydrophilic on January 25, 2008, 12:56 PM
Now I get it!
The answer is because BASIC reports 122365 bytes free. That equals 119 K (rounded to the nearest K).
Ha, ha!
No, No! (good idea)
But, where is the difference between the first kernal and the later one?
All kernals are reporting the same value!
We are surching for a real bug - and because I didn't have an international C128 (but a German C128D with 16k VDC), I only can assume that also the first kernal of the international flat C128 has the same bug.
WTE
It reports correctly but the BASIC pointers are set incorrectly, shorting you 9k?
Quote from: airship on January 26, 2008, 03:30 AM
But why does it?
Space is reserved for VIC bitmap mode.
No and No!
I'll give you a hint how I "calculated" the lost 9k (128-119=9).
First the C128 has 128k RAM (that's why he is called a C128) ;D
Using Basic you can't use all memory for your program code.
Some is used by the interpreter and kernal, some is used as memory for the variables, some is used for VIC text/graphics.
But this use is usual!
But this is not usal: The bug steels approx. 9k of memory from my code bank (bank 0).
And as I know now the bug was available in all early kernals and Commodore fixed it in later versions.
I discovered the bug in 1986 after some strange program crashes based on destructed program code.
I called Commodore in Frankfurt/Main but the expert was not reachable (I tried it several times).
So I wrote an article for the German RUN magazine but this mag was discontinued (1988) before publishing my findings.
Late 1988 the 64er published an article from an other dude dealing with "my" discovery. >:(
WTE
I LOVED the capslock Q bug, it showed how bad the QA department was and how useful the usergroups would have been if we had engaged them sooner.
For a time the C128 only had 64k due to a mixup in the films at MOS, they introduced a design artifact by mixing up layers belong to various revs that had all of bank 0 bleed into bank 1. We almost didn't see it as Terry stored program from the top and variables form the bottom (or vice versa) and we got into a program big enough to actually see it. after that it could be tested with a 3 line basic program... QA was still learning Basic at the time tho....
Bil
Quote from: BilHerd on January 28, 2008, 03:26 AM
I LOVED the capslock Q bug, it showed how bad the QA department was
And funnily (or sadly) enough, I dont think QA has improved in the last 23 years Bil. Ours is next to useless.
Ok - some last hints:
Think on VDC and MMU
or use Google.
WTE
Google's cheating. Even though I had to use Amazon to get the answer to my last 'win'. :)
Isn't there anybody out there who knows about this bug?
Maybe you all are VICE lamers and don't have a real C128? >:D
Or maybe you all are lucky fellows and have only a "new" C128 and not a real old (first kernal, 16k VDC) version?
I'll lift the enigma tomorrow! ;/
WTE
So... no one here has thought to check wte's website? ;)
Quote from: Michael Hart on January 31, 2008, 10:19 AM
So... no one here has thought to check wte's website? ;)
Cheating!
I've got a 16k VDC machine with original kernal and still don't know! Never stumbled across the bug appearantly. Of course I usualy take over the whole machine and use the kernal only for keyboard/screen/disk I/O... in other words, if the bug affects RAMTAS, PHOENIX, cassette, RS-232, etc then I'd never know.
I checked wte's website and couldn't find the answer. Of course I can read German about as well as I can walk on the Sun. If they spoke French or Spanish over there I'd have better luck. I've got a PDF of the German version of the C64 PRG which I like to look at occassionaly. Sometimes I can actually figure out what they're talking about due to context.
I can't wait for the answer to be revealed...
Ok, it's over now.
Read this: http://www.c128.net/articles/c119.htm >:D
Ha, ha, it's German!
The google translation (http://translate.google.com/translate?u=http%3A%2F%2Fwww.c128.net%2Farticles%2Fc119.htm&langpair=de%7Cen&hl=en&ie=UTF-8) is real crap.
So if you have an old C128 try this in 80 column VDC mode:
30 graphic 5
40 print chr$(147)chr$(27)"f";
50 char 1,10,10
60 getkey a$: print a$
90 end
The cursor is blinking on the wrong position!
What is the problem? The CHAR command is faulty!
CHAR is used in VIC text mode, in VIC graphic mode and! in VDC text mode.
To output the text string with CHAR 1,x,y,"text" basic enables bank 0 for writing and ROM/CharROM for reading (write RAM, read and execute ROM/CharROM) using MMU PreConfReg $FF03 (ROM code at $6815: sta $ff03), which is a good idea if you have to print to the VIC hires screen the pixels of a char but is not if you have to output some data to the I/O area. Hey you may think: "the print data is going to the VDC RAM that is ok, isn't it?" Yes it is. The output of the string data is ok. But before printing, the CHAR routine is setting the cursor position! No problem for VIC modes (cursor position is only updated "softly" in the zero page) but not so smart for the VDC who needs an update of the cursor position in register $e/$f of the VDC. The routine calls PLOT ($928d is called by ROM address $6838: jsr $928d) to set the cursor and this is done with the wrong configuration: CharROM is enabled and I/O disabled. Not a good idea. The result? The VDC never gets the correct cursor position info (so in our example the cursor is blinking on the wrong position). Is that a problem? No, not for the VDC, the printing position is ok. But where are the data gone? Blowing in the wind? Lost in space? No! Writing to ROM (here: CharROM) is writing to RAM! CHAR destroys $d600/d601 in RAM bank 0. In RAM bank 0 is your BASIC program. If your programm is longer than 50k (or 40k with VIC GRAPHIC ON) you need also the RAM above $d600 (up to $feff). Using CHAR in 80 column VDC mode (GRAPHIC 5) is killing your program: blinking lines (with LIST), broken line links, syntax errors and other "features" more.
The updated BASIC ROM uses code from $7e82 et sqq. for patching this and some other errors. The new subroutine is called from $6838 (jsr $7e82 instead of jsr $928d).
Using CHAR on a 80 column screen steals you the RAM between $d600 and $feff for BASIC. You are loosing 9k of BASIC RAM.
You should always keep in mind (if you are a programmer) that old C128 have this bug!
I hope it was understandable? You don't have problems if you don't use CHAR or don't use the VDC or have only a short BASIC program but I had a lot of trouble with this problem, a lot of trouble!
WTE
This wins my vote for best trivia question so far. Not that we were voting.
So... if one complained to Commodore about this bug, would they provide you a (free?) fixed ROM?
QuoteSo to the remaining nine KBytes for BASIC programs to be able to use, it requires a little Kunstgriffes.
Thanks to Google, I have a new favorite saying: "It requires a little Kunstgriffes." :)
I think Bablefish does a better job at translating. Slang is usually a problem though.
http://babelfish.altavista.com/ (http://babelfish.altavista.com/)
QuoteThis wins my vote for best trivia question so far. Not that we were voting.
Thank you for the flowers. :)
Kunstgriff := artifice, gimmick, trick, ... [See LEO (http://dict.leo.org/ende?lp=ende&lang=de&searchLoc=0&cmpType=relaxed§Hdr=on&spellToler=on&search=Kunstgriff&relink=on) - my friend in need, indeed!]
WTE
LOL, that sounds like a really nasty bug to track down. I remember a similar nightmare with an assembler I was writing back in the day. I never did figure out the bug. Thinking about it now, I'm sure it was due to the CPU's indirect JMP bug. Sad that CSG never released a patched CPU. At least you tracked down the bug and reported it, so congradulations!
Quote from: wte on February 01, 2008, 10:23 AM
Using CHAR on a 80 column screen steals you the RAM between $d600 and $feff for BASIC. You are loosing 9k of BASIC RAM.
It's not stolen & you haven't lost it. Someone else just decided to tramp all over it.
QA departments that don't share the blame for problems will never work.
All they do is point fingers, when a problem slips through then they still point the finger.
Nothing is ever their "fault".