Fooling around with DE00
Marko Mäkelä
The following article was also sent to the c64-h...@lists.funet.fi mailing
list that has been idle for a while, and to some individuals. To join the
list, which should be used for c64 hardware related discussions, send a mail
message to mail...@lists.funet.fi with the line
subscribe c64-hackers firstname surname
where firstname is your first name and surname your surname. You can also
determine who subscribe to the list by including the line "review c64-hackers"
to your message. Finally, the command "help" provides some help in using the
mail-server. The mail-server is not only for mailing lists, but you can also
use it for retrieving files from the FTP.FUNET.FI file archive if you do not
have FTP access.
Enough hype, here is the article:
I decided to write something to this list, as (1) someone asked why there is
nothing going on, (1=) I was the one who requested the creation of this list
and should actually answer the question, and (2) as I saw a post from an
emulator writer (Wolfgang Lorenz) on this list. He, like most C64
programmers, has the wrong idea of the open address space, as he has filled
the area $DE00-$DFFF (on the I/O space) with some constant data in his
emulator.
As some of you may have noticed from the news group comp.sys.cbm, I have been
experimenting with the video timing by reading open address space with the
processor. The common misbelief is that you get random bytes when reading
from $DE00. No, the RAM chips will still drive the data bus with a weak
current, and the processor happily reads the data that was requested by the
video chip on its clock half. (You know, the video chip and the processor
share the data bus and some of the address bus so that there will be two
memory accesses on each system clock cycle.)
Now I have the complete timing diagram of all PAL C64's and C128's
(MOS 6569 VIC-II and MOS 8566 VIC-IIe), and I also have a diagram of one
NTSC video chip, the 64 cycles * 262 lines version 6567R56A. If you like to
ask anything about the timing, feel free to e-mail me. And if you are in the
NTSC land, please measure the timing of your system with my test programs and
send the results to me. As I don't have direct net access at the moment,
it's better that you request the measurement programs from Andreas Boose,
whose E-mail address is <bo...@unixserv.rz.fh-hannover.de>. If you cooperate,
the complete NTSC timing can be documented as well.
Open address space is not only useful for measuring the timing.
You can also run programs on it. Naturally this requires a cycle accurate
timing, and branches are a bit difficult to implement, as the program counter
of the processor does not have any effect when running code on $DE00-$DFFF.
Well, a branch instruction directly followed by a three-cycle instruction
allows you to skip a two-cycle instruction. Here is an example of this
technique: A9 10 2D 01 DC xx F0 xx 24 A9 01 8D 20 D0. The bytes marked with
'xx' can be anything. The code will turn the border black when the space bar
is not pressed, and otherwise white.
The only problem with the $DE00 technique is that it does not work reliably
on all units. The DRAM chips drive the data bus so weakly that the processor
might sometimes read a '1' instead of '0'. This happens especially on C64's.
The C128 mother boards sit in a good Faraday cage, so they should work
reliably. I have measurement data from three C128's, and all were free of
distortions. On the other hand, as I made some measurements on a C128DCR
board that laid on the floor without any housing, there were very many
distortions.
I made my first DE00 program some weeks ago. I had to make a separate version
for the 64 cycles/line NTSC video chip. That program ran in text mode. Well,
but Andreas Boose asked me if I have made a $DE00 program that runs with
blanked screen. That was a bit hard to implement, but nothing is impossible
with the 64. The program should run with any video chip. It requires also
very little address space, from $DE00 to $DE07, but this area can be in use
with many cartridges. If the program does not run on your computer, try
turning off any unnecessary electric equipment, like disk drives, and
increasing the distance between the computer and the display.
The $DE00 program should turn the screen white. When you press the space bar,
the middle of the screen (the area between the raster lines $69 and $CF)
should turn black. You should be able to quit the program by pressing STOP
and RESTORE, provided that the computer has not jammed.
Here is the binary in uuencoded format:
If you don't understand the operation of the program, feel free to ask me
or Andreas for explanation.
Another interesting address area is the color memory ($D800-$DBFF). The
lower nybble comes from the color RAM, but the upper nybble is open address
space, just like $DE00-$DFFF. It would be challenging to make a program that
runs on the color memory with blanked screen. (On bitmap screen or on
text screen it would not be any big problem.) Branches are more difficult
to handle, as the processor's program counter does affect the lower nybble
that comes from the color RAM. Finally, on the C128 you could easily combine
the two techniques by making a program that runs partially on $D700-$D7FF and
partially on $D800-$DBFF.
Regards,
Marko
Jeff Epler
some units), what use does this have? What can I do more easily with
code I've made run using the $D700 hack than with normal code running
in normal RAM?
Jeff
--
____ "I wonder if you think about me once upon a time
\BI/ in your wildest dreams" -- Moody Blues V-- Pink Floyd
\/ "There's a change that, even with regret, cannot be undone"
IRC: Synger Running Linux 1.1 -- Free Unix for 386+ machines
Ivan
: Besides being difficult to emulate (and sporadically functional on
: some units), what use does this have? What can I do more easily with
: code I've made run using the $D700 hack than with normal code running
: in normal RAM?
Mmmmm.... write "emulator-protection"?
--
Firefoot/Style
fire...@netaxs.com
215/579-0336
"Where's my Tractor?"
DUCK@PEMBVAX1.PEMBROKE.EDU (CRAIG TAYLOR)
> In article <32cqo8$d...@netaxs.com>, Ivan <fire...@netaxs.com> wrote:
>>Jeff Epler (jep...@herbie.unl.edu) wrote:
>>: Besides being difficult to emulate (and sporadically functional on
>>: some units), what use does this have? What can I do more easily with
>>: code I've made run using the $D700 hack than with normal code running
>>: in normal RAM?
>>
>>Mmmmm.... write "emulator-protection"?
Actually I'd call it more along the lines of "If you're really bored and wanna
do something that'll make people whose looking at your code go huh..." :-)
Actually from reading the descriptions etc I'm wondering if it's safe to assume
the many C='s still have the RF shielding that is nesscesary for this to work
as I've removed the RF shielding that made my C=64 run hot with no loss of
video resolution (albelt I'm not sure about the neighbor upstairs and _don't_
tell the FCC I did it... <g> I did keep it on the 128 as it still serves to
function as a heat sink) ...
> Better call it "C64 protection". None of the programs Marko Makela
> posted works on any of my 3 C-64s. I believe this protection is a
> little too hard to overcome :-)
>
> -- Dave
>
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Craig Taylor (910)521-3814 The sayings I uttereth I utter for myself only.
* du...@pembvax1.pembroke.edu(preferred) _or_ c.tay...@genie.geis.com *
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
If you raise your hands to heaven you will live a hundred years. I stood there
like a mystic lost in the atmosphere. The clouds were suddenly parted - for a
moment I could see the patterns of the landscape reaching through the eastern
sea. I looked upon a prism spanning fourty centuries. I stood at the top of the
mountain and China sang to me. In the peaceful haze of harvest time a song of
eternity. - Tai Shan / RUSH.
Paul David Doherty
>: Besides being difficult to emulate (and sporadically functional on
>: some units), what use does this have? What can I do more easily with
>: code I've made run using the $D700 hack than with normal code running
>: in normal RAM?
>
>Mmmmm.... write "emulator-protection"?
Better call it "C64 protection". None of the programs Marko Makela