Re: Several answers (3)

From: Marko Mäkelä (msmakela_at_cc.hut.fi)
Date: 1998-03-31 22:40:10

On Tue, 31 Mar 1998 rbaltiss@worldaccess.nl wrote:

> I do have a German C128 as well. (They were much much cheaper then here
> in the Netherlands) And the CHARROM is a 2764 = 8KB in my case! 

That is because there are two complete character sets, selectable with the
ASCII/DIN key.  (On Swedish/Finnish adapted models, the key is ASCII/CC,
and on American models it is CAPS LOCK.)  On the American model, the
character ROM is also 8kB, a 2364, because the character set is a bit
different in the C128 mode than in the C64 mode.  (See the b, d, f, i and
a few other lower case chars, or the reverse @.)

> Later I found out that the Beta/Ringel-S replaced the @. Is that normal
> or just the case with the PETs? (My German C128 has a @) 

It was quite normal that national characters replaced some of the PETSCII
(or ASCII) characters.  Usually the characters that were sacrificed were
in the set [\]{|}^~@`.  I don't know the German ASCII variant, but in the
Swedish set, these were replaced with ÄÖÅäöåÜüÉé (the last four ones only
sometimes, and not in the Commodore charsets I have seen).

> The manual of my REU says:
> --- The C128 must be in 1 MHz mode when a DMA transfer is wanted. ---

That's Commodore's answer.  Andreas and I were looking for the real
answer, which probably is that something evil happens right at the end of
the transfer (nobody drives the bus on the halfcycle following the last
REU cycle).  You could perhaps avoid it by arranging it so that there will
be videochip DMA (well, RAM refresh in this case) right at the end of the
REU transfer.

If you want 100% emulation, you must analyze these things.  With some
luck, you might even be able to tell why it works so.  The exact operation
of the $d011 register has been solved; this is much simpler!

> Could you give us some details? Is there anybody else who has done some
> research in this area? 

I have measured some of the REU characteristics earlier.  It is a very
simple device that transfers and compares 1 byte/cycle and swaps 0.5
bytes/cycle between the C64 memory and the REU memory.  You can build a
REU clone by following the description on ftp.funet.fi.  There's no magic
except this 2MHz mode thing, which depends more on the C128's behaviour.

Some C64 emulators include REU emulation.  VICE for one has it, but I
haven't looked at the code, so I can't tell how compatible it is.

> If the output of a black box does not behave as expected with the given
> input, then we either mis-interpreted its function or the damned IC is
> simply damaged ;-) 

Or our model of the system is inadequate.  I don't like words like
"unexpected", "indefinite" and "unspecified" when it comes to the
behaviour of digital systems.  There are some temperature-dependent or
"random" things in the C128, but this REU thing is not one of them.

I agree that it is difficult to find out some things, like the operation
of the $AB opcode and the reason of the semi-random behaviour of
unconnected I/O address space ($de00-$dfff) on some units.  (The values
you read from $de00-$dfff reflect the data that was present on the bus on
the previous cycle, but there are some random bit errors in the data on
some (maybe most) C64s and C128s.) 

	Marko

Archive generated by hypermail 2.1.1.