C128: Z80 and FAST mode
Linards Ticmanis
has anybody ever determined what exactly happens when you switch the
C128 VIC to FAST mode while the Z80 is active?
Maybe someone has looked at the Z80 clock with a 'scope in this situation?
--
Linards Ticmanis
Craig Taylor
Since you haven't gotten a reply I'll hazard a guess:
1) I believe the Z80 is unaffected by the clock speed of the 8502
processor - it functions normally at whatever speed it is. Note that
there is a 'feature' of having to wait for the bus to settle when
switching back from Z80 mode when the 8502 is in 2mhz mode.
2) Since fast normally disables the VIC then you wouldn't have the
ocasional bad VIC scan-lines slowing the Z80 down (I think the Z80 is
also slowed by the VIC but not 100% positive).
- Craig Taylor
http://www.ctalkobt.net/cbm
news.comcast.giganews.com
equivalent speed of 4mhz except that we let two clocks go by and then wait
for a 500ns for a dram cycle (whether one is needed or not) and then two
more clocks, etc. This works because no Z-80 cycle finishes in less than 3
clocks so a dram cycle gets in there whether you need one or not.
In the 6502 memory access happen like clockwork, Phi2 goes high for the
start of access and the memory access ends when Phi2 goes low. In the Z80,
you get more of an "on demand" arrangement, a memory access can start on
clk2, clk3 and maybe clk4 which would appear to be any one of 4 windows but
kinda asynchronous. Any bus sharing vid chip would tend to hate this, which
is why we created the VIC window and the memory access window.
We ran into one little problem with this in in that if you freeze the Z80
just right for a clock stretch to occur, the internal bus of the Z80 floats,
however the output data buffers of the Z80 are on so it's an "amplified
float" a very solid 1v output that external pull-ups cant change. When a 1v
signal gets into the DRAMS or address multiplexers it pretty much destroys
the contents of DRAM as things oscillate since 1v is neither a low or a
high. People thought that changing the LS257 address multiplexers changed
the timing but the reality is it changed the voltage that they were
susceptible to oscillation at. This is what was wrong with tens of
thousands of CPM carts and why people thought that there was a timing issue
(there was a voltage issue)
We added circuitry in the Z80 stuff (thanks to Frank Palia) that allowed the
"floaty" cycle to go ahead and continue since it wasn't intended to be a
memory cycle anyways (it only became a memory cycle when it oscillated the
address bus) Thats basically what some of that mess is in discreet TTL
around teh Z80.
Bil Herd
"Craig Taylor" <ctal...@gmail.com> wrote in message
news:1185200960.5...@22g2000hsm.googlegroups.com...
Linards Ticmanis
> On Jul 22, 11:29 am, Linards Ticmanis <ticma...@gmx.de> wrote:
>> Hello,
>>
>> has anybody ever determined what exactly happens when you switch the
>> C128 VIC to FAST mode while the Z80 is active?
>>
>> Maybe someone has looked at the Z80 clock with a 'scope in this situation?
>
>
> 1) I believe the Z80 is unaffected by the clock speed of the 8502
> processor - it functions normally at whatever speed it is.
It seems that it runs somewhat faster though not twice as fast. I did
this experiment many years ago so I'm not sure, but I seem to remember
that he 40char screen was blanked to border color in the first place, so
the faster speed does not seem to stem from this.
Also it seems that interrupts almost unavoidably crash the Z80 in FAST
state. Turning off interrupts (DI) seems to be unavoidable if you want
to "survive" this mode. Without a scope that was pretty much all I could
discover.
Since the Z80 clock has two peaks for one half of the 6502 phase and
then none for the other half to allow the VIC to read memory (like
go-go-stop-stop-go-go-stop-stop..) it would seem to be a logical next
step to make it go another two steps in the other half of the phase for
FAST mode. But obviously that is not what happens.
Also it is interesting that the CP/M source code CBM distributed
contains many inactivated instances of this speed switching. It must
have been part of some original plan that didn't materialize. I'd guess
they never got it to work right and then decided to go to market anyway
since they couldn't spend any more time.
--
Linards Ticmanis
Linards Ticmanis
Bill, I feel very honored to be answered by you... I had emailed Von
Ertwine about this back then (mid-90s) but he was probably too busy, if
I even got the right Von Ertwine in the first place.
I'll write a better answer after taking some time with a schematic,
which won't happen tonight though, it's getting late on this side of the
pond.
Off-topic, and I know you aren't what one would normally consider a pop
star... but it's somehow strange to actually communicate with people who
you thought were these far away gods when you were a teen. I remember
getting an answer from Dennis Ritchie once in a newsgroup, and I was
really surprised that he seemed a pretty normal and friendly guy rather
than some higher power. Or when I got the chance to discuss the Ultima V
fast loader, that I had hacked around with (long and unsuccessfully)
when I came out in 1988 because it didn't work on the PAL C64, with its
programmer "Dr. Cat" also on usenet many years later. He was rally cool
and thanked for the bug report even though it came about twelve years
too late. The whole concept of ever talking to the actual programmer
about this problem would've seemed totally ridiculous to me when I was a
pimply German kid with poor English skills in 1988.
--
Linards Ticmanis
Simon Scott
> Off-topic, and I know you aren't what one would normally consider a pop
> star... but it's somehow strange to actually communicate with people who
> you thought were these far away gods when you were a teen. I remember
> getting an answer from Dennis Ritchie once in a newsgroup, and I was
> really surprised that he seemed a pretty normal and friendly guy rather
> than some higher power. Or when I got the chance to discuss the Ultima V
In a similar fashion, in the early 90s I posted on usenet asking about
some odd 'arcnet' cards we had found and how we could get them going with
DOS to play DOOM. One guy answered, and explained in detail how they
worked and pretty much surmised they were no good to us. A few emails
bounced back and forth, and we were surprised to find that the guy was
actually the engineer who had created arcnet.
Just one of those 'wow, the internet is cool' moments :)
hg
"Simon Scott" <scotty...@amnet.net.au> wrote in message news:11852758...@angel.amnet.net.au...
I had a similar feeling when the first item I ever sold on Ebay (a c64 game) was purchased by the guy who wrote it :-O
I won't say who it was, but all I will say was the game was a classic from '86 and the guy was a 'celebrity' programmer back then.
news.comcast.giganews.com
"Linards Ticmanis" <ticm...@gmx.de>
>>
>> Bil Herd
>
> Bill, I feel very honored to be answered by you... I had emailed Von
> Ertwine about this back then (mid-90s) but he was probably too busy, if
> I even got the right Von Ertwine in the first place.
>
Von's a cool guy, he probably just didn't get the email. I mean cool when he
isn't tackling me in the middle of the MGM lobby in Vegas (had a rug burn on
the side of my face for the rest of the CES show from sliding 10 feet face
down.... it was a cheap shot but a good hit)
> I'll write a better answer after taking some time with a schematic,
> which won't happen tonight though, it's getting late on this side of the
> pond.
>
> Off-topic, and I know you aren't what one would normally consider a pop
> star... but it's somehow strange to actually communicate with people who
> Linards Ticmanis
Cool meeting somone that remembers the old stuff.. In response to your
other comment it probably runs a little faster when the VIC DMA's are turned
off. ow... I think I just burst a vessel in the heda thinking that far
back.
Kind regards,
Bil Herd
bilherd
I seem to remember this. We had inherited an architecture from the Z80
cartridge and then made changes where we wouldn't stop a cycle at certain
points due to an amplified bus float condition and I even think we traced
some corruption to where we had to not release the reset line in the middle
of an AEC cycle. For the most part we assumed that most instructions worked
with the stutter clock when we started and only found exceptions when we
really tore into it ourselves. (In the end, a guy named Frank Palia tore
all of the examples apart and laid them on the table)
I believe that given the timeframes and goals that we would have said oops,
there's four cycle types you can't use on the Z80 but we can still run CPM
since the OS is in theory is doing the I/O. Yeah it sounds kinda cheap now
but I am sure that the next 4 decisions would have dealt with how to wack
management that was totally trying to derail the project or at least piss on
it so they could say they had some influence.
This is a good write-up in the link below, I remember Dave Haynie and myself
creating that timing drawing on the mentor workstation ourselves for our own
internal documentation, which later got picked up into manuals. It's always
weird to see something that you drew 22 years ago.
Bil Herd
>
> There is also a naughty hardware bug that nobody is going to mention...
> It's not even mentioned in any repair guide, etc. I have however a page
> that presents the bug, and why it happens, in about as clear of a context
> as I can. The URL for that is
>
> http://dr.ea.ms/c128hardwarebug.html
>
> There is one other that I am aware of, and it affects IRQ, however the
> software fix for that one is well documented in the BIOS. IRQ *CAN* work
> on the z80, you simply have to know how to be prepared for one...
hg
Changing the subject, did you and the team ever think about enhancing the VIC-II and SID chip in the 128? I guess that was never in
your instructions from the top, but would you have upgraded the video and sound if you had the time and resources?
bilherd
"hg" <h...@hg.hg> wrote
Hi hg,
Actually what we did didn't come from the top, we basically started at the
lowest level of thinking we could do something and then aquired resources
and permissions from there.
With that said here are my (rather lng) thoughts about the state of things
in mid 1980's as far as what could be upgraded.
I think that there is a basic concept that the VIC was maxed out for the
architecture.
Remembering that damm near every part of the C64 was maxing out the
technology for the day, you have multiple areas all relying on each other:
Output resolution set by TV
320 x 200 for the color bandwidth and NTSC limits
Number of colors (set somewhat by technology and the depth of the color
fetch)
16 distinct phases on the color wheel
Memory speed (set by the fastest DRAM's of the day of 150ns, we used 200ns
typically)
Memory size - really the buffer is set by the resolution, bigger doesn't
matter.
Not to mention it was all we could do to store and move around a full screen
using a 1mhz 6502. A thumbnail on the internet is bigger than our entire
operating system, it would take quite a few seconds to transfer on or pull
from drive
RESOLUTION
When you look at the out put side, the TV side there is a maximum number of
pixels that may contain color, 320. This is set by the fact that chroma
bandwidth has a very top end of 3.58mhz (color burst). When you change the
information faster you create an artifact because you don't have enough of
the 3.58 color carrier to present a valid phase shift signal against. When
you do go to fast you see the color rainbows (chroma artifacts) typically
ping and green. So the horz max is set to 320.
The Amiga did a VERY SLICK thing when it used HAM (Hold and Modify mode)
they would make a color at the max speed (< 3mhz) buy then toggle the
intensity a second time per pixel. This gave a second shade but much more
detail. This really happens on color transmissions the color changes slower
than the "detail". As an old TV repairmen we would look for the spaces
between actor's teeth as an indication of whether the luma/intensity
bandwidth was okay on a TV. So adding pseudo resolution took an entire
revolution in thinking.
NUMBER OF COLORS
I looked at the chroma signal on a vectorscope back then. Between all of
the clock noise and IM type modulations the 16 colors bled into each other
as it was. THE TED did have more colors but a whole different architecture
for fetching the color information. So to get a TED (Plus 4) palette buy a
Pluse 4 (we had LOTS in stock cause for some reason when you sold a $79
computer for $299 it didn't sell as briskly as one would suppose if one
worked in marketing and had their head up their arse) but for a C64 pallete
use a VIC.
NUMBER OF SPRITS.
Hoo boy. bus already maxed out, chip already absolutely full. Would
probably have broken serial bus timings to steal more time for sprites if
people actually needed more sprits.
Memory bus width and cycle time all locked. At the end of the day, the NTCS
TV timing requirements dictated the system,. The only way forward was a
massive revamp like the Amiga of to break free of the TV as an output
device.
Interesting note: at the time the C128 came out there was only a couple of
80 column monitors on the market. I was told to screw up the sync
polarities on the RGB monitor signal to force people to but the Commodore
version of the monitor. I actually lied when I said I would do what I was
told and then was non-committal in the progress. (I didn't do this lightly,
I value honesty and the integrity of my word so I took into account many
things and lot's of rationalizing. in the end I decided that an idiotic
demand deserved an idiotic answer). So because I made it "standard" there
were monitors available when the 128 came out (we were late with ours by
many months) which forced ours to be standard as well which meant they could
actually be used more often themselves.
So I didn't really see much that could be improved in the
VIC/Memory/processor architecture other than to bank in more ram and
eventually add animations with the DMA capabilities of the 512k cartridge
(that was a sweet little gizmo for it's day and Terry Ryan wrote the DMA
commands right into Basic 7.0 before there ever was a DMA gizmo Put and
Fetch.
We added an 80 column chip as the only other logical addition and it almost
brought the project down waiting for good silicon.
They were working on a better SID, steeper filter rolloff, less noise, but
the chip designer didn't actually know how to start-middle-complete a
project. he just did revision-research-revision-research
The Vic and Sid were very sweet objects for their day, there wasn't anything
that I could really add to them so I concentrated on the platform itself
with faster clock when I could, bigger memory and making sure that the
timings actually worked.
Hope this answers the general form of the question.
regards,
Bil Herd
Sam Gillett
<Bil Herd> wrote ...
>
> Interesting note: at the time the C128 came out there was only a couple of
> 80 column monitors on the market. I was told to screw up the sync
> polarities on the RGB monitor signal to force people to but the Commodore
> version of the monitor. I actually lied when I said I would do what I was
> told and then was non-committal in the progress. (I didn't do this
> lightly, I value honesty and the integrity of my word so I took into
> account many things and lot's of rationalizing. in the end I decided that
> an idiotic demand deserved an idiotic answer). So because I made it
> "standard" there were monitors available when the 128 came out (we were
> late with ours by many months) which forced ours to be standard as well
> which meant they could actually be used more often themselves.
I never tried using a C128 with a genuine "Big Blue" monitor myself.
However, I heard from several sources that a real IBM CGA monitor would not
work with a C128, but that most "clone" CGA monitors would work.
I did have an Emerson XT clone and an Emerson CGA monitor (about a 1987 model
IIRC). The Emerson monitor worked great with my C128. As a mater of fact,
it provided brighter color and sharper text display than my Commodore 1902A
monitor could.
Of course the Emerson monitor did have a couple of major drawbacks. It had
no speaker, and worse yet, could not be used with 40 column mode. Although I
used 80 column mode most of the time, I did like to be able to use C64 mode
once in a while. So, the 1902 monitor stayed hooked up to my C128 most of
the time. :-)
--
Best regards,
Sam Gillett
Change is inevitable,
except from vending machines!
hg
<Bil Herd> wrote in message news:jZadndKMPPUJgjDb...@comcast.com...
>
> "hg" <h...@hg.hg> wrote
>> Bil,
>>
>> Changing the subject, did you and the team ever think about enhancing the VIC-II and SID chip in the 128? I guess that was never
>> in your instructions from the top, but would you have upgraded the video and sound if you had the time and resources?
>
> Hi hg,
>
> Actually what we did didn't come from the top, we basically started at the lowest level of thinking we could do something and then
> aquired resources and permissions from there.
>
> With that said here are my (rather lng) thoughts about the state of things in mid 1980's as far as what could be upgraded.
>
Thanks for your detailed reply, Bil. That was interesting reading. So basically, if the 64 hardware had allowed you to enhance the
sound and graphics you would have upgraded them, but the 64 design was so tight not much could be done.
Cameron Kaiser
>Interesting note: at the time the C128 came out there was only a couple of
>80 column monitors on the market. I was told to screw up the sync
>polarities on the RGB monitor signal to force people to but the Commodore
>version of the monitor. [...]
>So because I made it "standard" there
>were monitors available when the 128 came out (we were late with ours by
>many months) which forced ours to be standard as well which meant they could
>actually be used more often themselves.
Many of my friends used off-the-shelf CGA monitors with their 128s, and the
CGA->VGA boards Fotios and others have worked on now mean regular LCD flat
panels will work. I just got mine; have to go wire it up and put it in a box.
We salute your intransigence :)
--
Cameron Kaiser * cka...@floodgap.com * posting with a Commodore 128
personal page: http://www.cameronkaiser.com/
** Computer Workshops: games, productivity software and more for C64/128! **
** http://www.armory.com/%7Espectre/cwi/ **
Hernan Vergara
On Tue, 30 Jul 2007, Cameron Kaiser wrote:
> Many of my friends used off-the-shelf CGA monitors with their 128s, and the
> CGA->VGA boards Fotios and others have worked on now mean regular LCD flat
> panels will work. I just got mine; have to go wire it up and put it in a box.
>
> We salute your intransigence :)
Of course, that means also integrity and professionalism :-)
Hernan
Brian Ketterling
Hernan Vergara <hver...@vcsweb.com> wrote:
The C-128 project sounds like it was really crazy-making. Bil, thanks for
continually finding a way "ahead", and pushing in that direction. I hope
the kudos ever since have been compensation!
Brian
--
John Selck
<samgille...@diespammermsn.com> wrote:
> I never tried using a C128 with a genuine "Big Blue" monitor myself.
> However, I heard from several sources that a real IBM CGA monitor would
> not work with a C128, but that most "clone" CGA monitors would work.
Revision 2 of the VDC has a register where you can invert the polarity
of the sync signals. That should make it work. The 2nd revision of the
VDC is found in the C128DCR.
John Selck
On Mon, 30 Jul 2007 01:11:00 +0200, <Bil <"Herd>"> wrote:
> NUMBER OF COLORS
>
> THE TED did have more colors but a whole different architecture for
> fetching the color information.
Another idea of how more colors maybe could have been achieved
by replacing the stage where the 4 bit color information is
turned into chroma/luma levels and lead those 4 bits out of
the VIC instead.
Then, another IC could have 16 palette registers where each
of the original VIC-II colors would get a configurable chroma
and luma. This would have no effect on the behaviour of the
VIC so all C64 software should remain unaffect (except for
software writing to registers unused on the C64 *sigh*).
But I guess Commodore would not have allowed yet another
new IC :)
> NUMBER OF SPRITS.
>
> Hoo boy. bus already maxed out, chip already absolutely full. Would
> probably have broken serial bus timings to steal more time for sprites if
> people actually needed more sprits.
Looking at all the 8 bit homecomputers I know by now, the C64 easily
has the best sprites anyway. And even many of the later 8 bit
consoles don't look to good when it comes to their sprite engines.
There is a few minor changes which I would have liked on the VIC:
- 256 characters in ECM mode instead of 64
During bitmap fetches when ECM mode is enabled, there is a logic
which forces two of the address pins to 0. I would have liked to
see that logic removed, since ECM would be much nicer with
4 background colors AND all characters available.
- Enable character lines in upper/lower border areas
Another logic enforces that character lines only may start during
the rasterlines $30-$F7. A bit to disable that logic and ALWAYS
allow the start of character lines would have been great. Ofcourse
this would mess up with the sync signals, but a programmer could
use raster interrupts to limit the character lines to the
rasterline range he needs.
- Don't force illegal modes to color 0
The few "illegal" modes of the VIC still have the normal
bitmap/character logic running (you can see it if you put sprites
behind the black chars/bitmap) but the color is forced to black.
I guess some of these modes might have been useful, especially
the combination of multicolor and ECM would be quite interesting
for colorful games.
Anyway, this is just a bit of dreaming. Ofcourse it's now 20-25
years too late for such stuff :)
> The Vic and Sid were very sweet objects for their day, there wasn't
> anything
> that I could really add to them so I concentrated on the platform itself
> with faster clock when I could, bigger memory and making sure that the
> timings actually worked.
Concerning the faster clock speed of the C128: I believe that the
compability
problems could have been avoided by inverting the 2 MHz and test bit in
register $D030. The problem was that some programmers simply copied the
entire
register set of the VIC to RAM when writing the programs, modified the copy
in RAM and then made their program copy it back.
Some of those programmers didn't stop at the last legal register ($D02E) so
they wrote back what the VIC on their C64 would deliver on a read access
(which was: $FF). This enabled both, 2 MHz and test mode of the VIC which
caused disabled screen and then mostly a crash due to missing DRAM refresh.
But actually I don't think this is a big problem. Once you know that you
have to search for the routine which copies RAM to VIC, it takes just
a minute to find that routine (it's usually in the initialization phase
of the program anyway) and it's usually a 1 byte modification to fix
that routine.
Oh btw, another small incompability problem I encountered was the missing
SID mirrors at $D500-$D5FF. I actually found one program which had music
written for that mirrors (Frantic Freddie), but otherwise that program
ran without problems.
laters.
bilherd
sync in that crazy transistor circuit on the RGB connector that turned into
an exclusive NOR with opencollector gates and thre transistors something
equally silly. Management didn't understand transistors (or really that I
would use them this way to flip logic) and I could add transistors as a Type
2 approved change and didn't disturb FCC submission already in progress, the
open collector gates I used were literally the last unused gates on the
board at that stage. The total jumpers were under a 1/4" and I hid one
under a chip, all in the name of sliding through FCC without strting over.
For a good laugh if you read schematics, check out the massive sillyness
between U24 and Q1 at:
http://staff.washington.edu/rrcc/uwweb/C128/VID-VDC.gif The only thing I
will say in my defense was it was late, it worked, and it passed FCC and my
boss got fired not me.
Bil Herd
Glenn P.,
Easter Egg in the C128? And, are there any other Hidden Messages in there???
--_____
{~._.~} >>>> [ "Glenn P.," <C128UserD...@FVI.Net> ] <<<<
_( Y )_ -----------------------------------------
(:_~*~_:) [Disconsolate wail]: "I gotta BLUEBERRY for a daughter!"
(_)-(_) (From: "Willy Wonka And The Chocolate Factory")
:: Take Note Of The Spam Block On My E-Mail Address! ::
Glenn P.,
Would you have any interest in assisting developers to produce a
ultra-accurate software-based C64/C128 emulator???
Brian Ketterling
Bil Herd <Bil Herd> wrote:
> BTW, I hid the logic"change" of making the polarity the right way for the
> sync in that crazy transistor circuit on the RGB connector...
> ...For a good laugh if you read
> schematics, check out the massive sillyness between U24 and Q1 at:
> http://staff.washington.edu/rrcc/uwweb/C128/VID-VDC.gif...
Could you give a duffer some idea of what's going on there? To me, it looks
like R,G,B,I,H-sync and V-sync are all inputs, and Monochrome is the output.
How is it flipping the RGBI output's sync polarity?
Thanks,
Brian
--
Brian Ketterling
Glenn P., <C128UserD...@FVI.Net> wrote:
> Hey, Bil!!! Whatever moved you to insert that "Link Arms, Don't Make Them"
> Easter Egg in the C128? And, are there any other Hidden Messages in
> there???
I'd like a refresher too. I half-remember there being something like 3
easter eggs, and one mentioned in a user group newsletter that required 64k
VDC RAM (for proper color?) and a set of POKEs and SYSs to view.
Brian
--
bilherd
>> Detailed VIC specific tweaks listed <<
> There is a few minor changes which I would have liked on the VIC:
> - 256 characters in ECM mode instead of 64
> Another logic enforces that character lines only may start during
> > The few "illegal" modes of the VIC still have the normal
> bitmap/character logic running (you can see it if you put sprites
> behind the black chars/bitmap) but the color is forced to black.
> > I guess some of these modes might have been useful, especially
> the combination of multicolor and ECM would be quite interesting
> for colorful games.
I guess I always assumed that tweaks would be good for a few programs that
used it but I would have absolutely inssted that the Vic act like a legacy
Vic in C64 mode as I did not believe in "C128 vesrions of C64 mode" which
is why I made the MMU go away in C64 mode. I also didn't want to change the
architecture and create bugs, the 128 was supposed to be a slam dunk in in
that there shouldbn't be any reason the chips should go through revs once it
hit the street. In that we pretty much hit it, the 98% working stayed
working, we didn't have to open 'er up like we did some of the others that
were trully cutting new ground.
> problems could have been avoided by inverting the 2 MHz and test bit in
> register $D030. The problem was that some programmers simply copied the
> entire register set of the VIC to RAM when writing the programs, modified
> the copy
> in RAM and then made their program copy it back.
> Some of those programmers didn't stop at the last legal register ($D02E)
> so
> they wrote back what the VIC on their C64 would deliver on a read access
Ah yes, a true screw-up on my part, I remember the exact couple of seconds
when I decided to not ask the chip guys to make the registers go away and
not come back... I countered with picturing C128 mode where the register was
gone after a reset (there is no reset line on VIC if I remember, it wasn't
"aware" of some processor things) and you couldn't get it back. It flashed
through my head to make it so you write a specific pattern to a couple of
"phantom registers" to bring back the $30 register and I countered with
where we were at in the design cycle and what code was already beyond my
control in time for CES. The decision was over in two seconds but it was
affected by the preceding 3 months and the race to CES. I closed the
thought with "no correctly written program would write to that register"
which is just stupid given how much paranoia I used for the rest of the
design.
When I threw an logic analyzer on Escape From Fractalus to see how they
overwrote the bit I saw that the block transferred an entire chunk of 255
addresses just to write the bottom $2F... the rest was literally garbage and
a waste of time and processor. I had to laugh that I while I was still
right in in that this was not a "correctly written program" in nonetheless
was a C64 compatibility problem.
As I mentioned, it just happens that I remember the exact couple of seconds
that I made this mistake.
Bil Herd
bilherd
Hell I still have poor English skills. Good to hear form you.
Bil
bilherd
said, I think I was thinking of the monochrome circuit when I mentioned what
I had to do. Basically I had to make it still work when we used the syncs
"correctly" so all of the work IOhad to redo on the monochrome hid the fact
that the syncs were now half flipped in polarity (but standard). Wow, I
just blew another blood vessel trying to remember the full story....
Bil
"Brian Ketterling" <twee...@no-potted-meat-products-peoplepc.com> wrote in
message news:FhVri.14444$zA4....@newsread3.news.pas.earthlink.net...
bilherd
Don't know what help I could be but feel free to bounce things off me. With
that said, I barely remember how to spell VIC given it was 23 some years
ago.
Bil
"Glenn P.," <C128UserD...@FVI.Net> wrote in message
news:Pine.LNX.4.61.07...@Bfjrtb.SbkInyyrl.arg...
Brian Ketterling
Bil Herd <Bil Herd> wrote:
> They are all outputs and get buffered before getting "mixed".
Oh sure -- I meant R,G,B,I,H & V appear to be inputs to the "crazy circuit",
with Monochrome as *its* output.
> But with
> that said, I think I was thinking of the monochrome circuit when I
> mentioned what I had to do. Basically I had to make it still work when we
> used the syncs "correctly" so all of the work IOhad to redo on the
> monochrome hid the fact that the syncs were now half flipped in polarity
> (but standard).
So you kept the disapproved (but standard) sync polarity on the RGBI jack,
but flipped it for monochrome? Or vice-versa?
> Wow, I just blew another blood vessel trying to remember
> the full story....
Maybe its a physical memory of the blood vessels you had to blow *then*,
while jumping through multiple hoops!
Brian
--
bilherd
rather than made the polarities non-standard which would have worked with
the original Monocrome circuit. Monochrome was kind of an add-on and was
wheer the question of sysnc polarties came up, unfortunatley in front of
managment. I could probably have gotten it over-ruled but I picked those
battles due to time and the occasional unexpected outcome.
They thought that because Monochrome went back to working that I had done
what they asked, when in fact I had redesigned teh monochrome circuit. (real
real ugly but I couldn't make any changes such as add chips or even long
jumpers, that would flag the fact I had made a change that would have
brought attention to the fact that I had not bombed teh RGB syncs.)
Bil
"Brian Ketterling" <twee...@no-potted-meat-products-peoplepc.com> wrote in
message news:13b57s8...@corp.supernews.com...
John Selck
> I guess I always assumed that tweaks would be good for a few
> programs that used it but I would have absolutely inssted that
> the Vic act like a legacy Vic in C64 mode as I did not believe
> in "C128 vesrions of C64 mode" which is why I made the MMU go
> away in C64 mode.
I still liked the 2 MHz bit in C64 mode. Some programs/games took
advantage of it. Especially when it came to numbercrunching C64
programs it was VERY nice to have. I am thinking about compression
programs here, I remember that programs like CruelCruncher took
hours for compressing a 150 blocks program, and 2 MHz really was
a big relief here.
Wasn't many programs with 2 MHz incompability problems anyway.
> Ah yes, a true screw-up on my part, I remember the exact couple
> of seconds when I decided to not ask the chip guys to make the
> registers go away and not come back...
Just inverting those two bits in $D030 would've been enough.
> When I threw an logic analyzer on Escape From Fractalus to see
> how they overwrote the bit I saw that the block transferred an
> entire chunk of 255 addresses just to write the bottom $2F...
I remember two others: Hawkeye and Masters of the Universe.
> As I mentioned, it just happens that I remember the exact
> couple of seconds that I made this mistake.
I think it was more annoying for the companies which made the
mistake of writing there :D