C119!

Started by wte, January 23, 2008, 07:31 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

wte

Ok, it's over now.

Read this: http://www.c128.net/articles/c119.htm  >:D
Ha, ha, it's German!
The google translation 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


nikoniko

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

pearsoe

I think Bablefish does a better job at translating. Slang is usually a problem though.

http://babelfish.altavista.com/
My rig: C-128 w/JD SCPU, uIEC/SD, CMD-HD (500 MB), CMD-HD ZIP drive, CMD RAMLink, 1750XL 2 MB REU, FD-2000, 1581, Turbo232

wte

#28
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 - my friend in need, indeed!]

WTE

hydrophilic

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!

smf

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