OK, here are a bunch of questions about C128 video that have been rattling around in my brain for awhile. I'm sure the answers are all probably an obvious 'no', but I'd like to try to understand why.
(1) Can you just add a switch to the NTSC/PAL pad on the C128 and flip your VIC from one mode to the other? If so, do you have to reboot or can you do it on the fly? (I thought I'd start out with an easy one for an expert, even though I certainly don't know the answer.)
(2) Why can't you just add a chip to divide the VIC clock by 1/2 when you go into FAST mode so you can keep the 40-column display? I know the VIC is still performing some functions in FAST mode, right? It's not completely turned off. (OK, I've thought about it and I know dividing the clock is a dumb idea. D'oh! But isn't there SOMETHING you can do? Something that the Commodore engineers thought of, but management nixed because it might add a dime to the cost of the machine?)
(3) How much work would it be to hack in an INTENSITY value for the VIC and/or the VDC? Adding a hack to change the whole screen permanently wouldn't be hard - you could do that with one resistor! But how about to change intensity by frame? By character row? By scan line? (By scanline, maybe an 8-bit D/A converter inserted into the intensity line, mapped into I/O space somewhere and updated during refresh?) By character block? By pixel? I'm sure each of these is possible, somehow, but how practical is each? Of course, I'm thinking ultimately of 16 colors at 256 displayable intensities for each pixel. :)
(4) Could you add a little daughter board - something like CLD's 64k video RAM expander - to enhance the VDC or VIC video capabilities? Like with the luminance thing above, or to add more available scanlines, or more pixels per line, or MORE COLORS (especially more colors), etc.
(5) As far as that goes, how about programming a CPLD to take the place of the VIC or VDC chips? Seems to me like this would be an easy way to add enhancements. I know there are some that come in 40-pin formats, and there are 40-pin adapters for the others.
That ought to be enough to spark some discussion! :)
Quote from: airship(4) Could you add a little daughter board - something like CLD's 64k video RAM expander - to enhance the VDC or VIC video capabilities? Like with the luminance thing above, or to add more available scanlines, or more pixels per line, or MORE COLORS (especially more colors), etc.
The second version of the Graphic Booster 128 (http://www.c128.net/infos/gb128info.htm) was advertised as allowing 7200 out of 65000 colors at once.
The first version, as far as I can tell, was just a 64K VDC upgrade coupled with new BASIC commands for VDC programming. The ads claimed, though, that you could choose 2 colors out of 3000 in graphics mode or 16 colors out of 2000 in text mode. Seems doubtful to me, because after the 128 DCR came out with 64K VDC RAM standard, the Graphic Booster was rereleased as a simple ROM plus disk, and then simply a disk version with no ROM. So where were the extra colors coming from if special hardware wasn't needed?
8-Bit Nirvana has this little tidbit about the 'first version' of the board (auto-translated from German by Google) - was there ever really a second version?:
http://tinyurl.com/yold9q
"The notorious graph IC booster... the plate and the wire to the extra Rome base are only masquerade, so that all bought the plate; -) The normal change on 64K VDC-RAM does it exactly the same."
So the board was simply a 64K video upgrade like the CLD board, and the jumper wire coming off of it was just deception, according to this guy. And everything else was just normal 64K VDC programming - if there is such a thing as 'normal' when it comes to the VDC. :)
Thanks. That pretty well confirms my own conclusions about it.
I don't know whether the second version really existed or was just more hype -- I suspect the latter. Probably just another deception to try and sell the same 64K upgrade and BASIC extension.
I can imagine a possible video extension which wouldn't require any internal modification. The standard RGBI output could be passed through a circuit which reinterprets the signal before passing it to the monitor. Each color cell can normally have only two colors, background and foreground. The circuit would take every two horizontal pixels and transform them into one by taking two thirds of the first color and one third of the second color.
QuoteBackground-Background = Background (eg. 2/3 black plus 1/3 black = black)
Background-Foreground = 2/3 Background, 1/3 Foreground (eg. 2/3 black plus 1/3 white = dark grey)
Foreground-Background = 2/3 Foreground, 1/3 Background (eg 2/3 white plus 1/3 black = light grey)
Foreground-Foreground = Foreground (eg. 2/3 white plus 1/3 white = white)
Horizontal resolution would be halved, so for instance a 640x200 screen would become 320x200, but each color cell could effectively be 4x2 and would have more tonal range.
One would certainly need a switch to turn this feature off and on, as it wouldn't be desirable all the time. :)
But of course, being very ignorant, it's easy for me to imagine things which might not even be possible to do. Perhaps one of the smarter people here could weigh in on it.
4) Nikoniko, that's a neat idea. The only problem I see is aligning the bit pairs, and counting bits. Counting bits would need access to the 16MHz dot clock so at least a small H/W mod would be needed. With this, you could align bits by simply counting clocks; reset the counter every H sync.
Oh yeah, it sounds like the extra colors of the Graphics Booster is simply from dithering.
1) The different VICs have different internal timings. Most importantly the number of cycles per raster. Another reason a simple switch isn't possible is each runs from a different frequency master clock.
2)I don't know what the problem is! You would think with double frequency the VIC could produce 640 horizontal resolution with 16 sprites!! Of course you would need extra registers for extra sprites. I think Commodore expected the VDC to be the answer and left us with VIC only for 64 compatibility. Stupid! The VDC has no sprites, or raster/sprite IRQ... I will stop now before I really start ranting.
3)The VIC produces a composite output so it shouldn't be too much trouble to scale it giving intensity. You'd need to be careful to return to normal intensity during the sync signals; this would be difficult because there is no seperate Sync line from the VIC. Would be easier with the VDC in this case (it does have seperate sync) but you would probably want to scale all 3 RGB components seperately.
5)Good luck with that! These chips are monsters. Not only creating an image in real time, but also responsible for memory refresh. The VIC has extra functions too like scanning the keyboard and stretching the clock for I/O access. One of the few mods I would gladly pay lots of money for instead of do-it-myself.
Quote from: hydrophilic4) Nikoniko, that's a neat idea. The only problem I see is aligning the bit pairs, and counting bits. Counting bits would need access to the 16MHz dot clock so at least a small H/W mod would be needed. With this, you could align bits by simply counting clocks; reset the counter every H sync.
Interesting. Would you mind going into that a little more? Why couldn't a device derive the correct timing from the video signal itself? After all, monitors do.
The monitors interpret it (the R,B,G components) as an analog signal -- at least in the time domain. You need to get an ordered pair of 'bits' to do the color conversion. I'm not saying its impossible without the dot clock, but it would be soooo much easier with it.
You could set-up a (internal) timer to start counting when it receives the h-sync to do bit alignment but this has two problems. 1) the internal count could could be off by 1 so that your bit pairs are backwards and since order is important in your scheme, the color would go wacko (a software setting could scroll the screen by 1 pixel to compensate but that requires user intervention). More importantly 2) if your counter did not match the VDC dot clock exactly, there would be drift; the pixels could be fine at the start of the raster, crazy in the middle, and backwards at the end of the raster. This is with only 1 pixel/raster error. You're timer would need to be at least 1/2 pixel / raster accuracy or about 1/1300 accuracy. 0.07% is not impossible to achieve but would be difficult, I think.
I hope that makes some sense. Another way to think about it is: how long (in time)is each bit/pixel? What ever number you calculate, there is no gaurantee that any particular C128 will match exactly (in fact probably the opposite). Even if the match is good at startup, the frequency / bit-time will drift with temperature and power fluctuations. Maybe this drift wouldn't be enough to effect your device...
Edit
This is also related to what I said about the VIC. The sync and luminance are provided from the same pin. The sync could be extracted from this signal. Use an analog comparitor for example. Obviously this is possible (monitors do it), but is more trouble than a simple digital ciruit.
Quote from: hydrophilic1) the internal count could could be off by 1 so that your bit pairs are backwards and since order is important in your scheme, the color would go wacko
Yeah, that wouldn't be pretty. :tillfreds:
Hmm.
Well, assuming it were possible to tap the VDC's clock, I wonder how that could be communicated? Perhaps something could be rigged to transmit the necessary timing through the composite pin? (Assuming we don't care about giving it up.)
The dot clock goes straight to pin 2 on the VDC. A driver with hi-impediance (sp?) could input from there and output to the VDC connector. Composite pin is a good idea since your device wouldn't work with composite (or would it?!). Another idea is pin 2 of the connector. It is ground. We already have a ground on pin 1, we don't need two! Of course removing your device and plugging a monitor into the modded port might not like that!
Quote from: hydrophilicOf course removing your device and plugging a monitor into the modded port might not like that!
True. Then again, if the second ground or the composite pin, whichever one is used for the device, isn't important, an off switch on the device could not only turn off the video transformation but block the signalling from the repurposed pin. Aside from doing 80 column monochrome on a TV, does any actually use the composite?
I think I've realized a major snag, however. The monitor is only expecting the RGBI pins to signal 16 colors, right? So there there isn't actually be any way to send other colors... or is there? Will the monitor accept RGBI values that are not full off, full on, 0, 1 values?
Ooooh... the CGA monitor. I hadn't thought of that. From the 1902A schematics, it looks to me like inside the monitor the Intensity line might just be flipping 'on' and 'off' to select two levels. At least, there's a little 'square wave' icon in a little box, there right before the Intensity is mixed (via a resistor pair) with R, G, and B to go to the CRT guns. :)
I could be wrong, of course, and the odds are actually VERY good that I don't know what I'm talking about. But if it is the case that Intensity is just binary, then varying the intensity level wouldn't make any difference in the actual display unless you did a full conversion of the signal to RGBA and used a different monitor. Shucks.
But maybe you could still do it on the VIC side?
Quote from: airshipBut if it is the case that Intensity is just binary, then varying the intensity level wouldn't make any difference in the actual display unless you did a full conversion of the signal to RGBA and used a different monitor. Shucks.
That's an idea. RGBI to RGB is doable (http://www.softwolves.pp.se/cbm/maskinvara/scart.en.html).
QuoteBut maybe you could still do it on the VIC side?
That could work as well, turning the 320x200 mode into a specialized 160x200 mode. Combined with FLI, you could have 4x1 color cells. Unlike true multicolor mode, you couldn't have 4 different VIC colors in one cell, but being able to do nice gradations between two colors could make for some nice pictures. The major snag there, and most likely a deal breaker, would be sprites -- you couldn't really use them since they'd screw up the colors of the background image. A VIC-II without sprites... yuck.
But how about this for some more senseless and ignorant brainstorming... could there be a way to add real hardware sprites to the VDC display? What I mean is not replacing the VDC, but combining its output with the output of a sprite generator of some sort, allowing sprites to be overlayed onto the video signal. Ideally, I'd hope the generator wouldn't be limited to 8 sprites per line -- a minimum of 16, or more if possible. Also, if the interface takes the RGBI input, translates it to Analog RGB, then does its overlay, sprites wouldn't have to be limited to the 16 VDC colors. We could perhaps expand into 256 color territory. Anyway, sprites would pretty well compensate for having no direct access to VDC video RAM. :D
How about a video mixer that would take a black-background VIC screen with sprites and use it as an overlay (with the black transparent, of course) to the 80-column screen? You could create a black-foreground mirror of the VDC screen on the VIC screen to give your sprites something to collide with (a technique I read about somewhere on this board - maybe even from you, nikoniko!). Then you could use standard sprite commands to move and detect real sprites on the 80-column VDC playfield. Sprites could even go behind objects on the VDC screen by simply going behind the black foreground mask on the VIC screen. And, of course, you could use all of the standard screen-interrupt stuff to increase the number of sprites, use different colors, etc.
Too bad it would only work in SLOW mode.
I think I'm describing a genlock here, aren't I? Except it would have to mix standard video with CGA, instead of video with video.
Great idea! Since the VIC already has sprite generation hardware, that would simplify the device considerably. Despite not offering any new capabilities over existing sprites, you'd have the great advantage of programming them exactly the same as one is used to, and could even use the various tricks that are so popular in demos. Plus, you'd have the satisfaction of using the VIC and VDC in a lovely collaborative relationship.
So... all you need is a circuit that would:
(1) Lock the VDC and VIC chips together so that they do vertical retrace, horizontal retrace and line scanning at absolutely the same times & rates,
(2) Time everything so that the VIC draws one pixel for every 2 drawn by the VDC (pixel stretching?),
(3) Display 2 VDC pixels anytime there is a black pixel coming from the VIC, and
(4) Mix the two signals for display on, what, S-VHS?
Piece of cake. :förvånad:
Hehe... I wonder how much of a bounty we'd have to raise for somebody to do all that? :D
Damnit, Commodore... I know we weren't supposed to use the VDC for anything but text, but you had to know people would want their sprites, too. :) I guess with the Amiga out at the same time, though, there wasn't much reason to develop the 128's capabilities into something more.
Maybe we could start with one of these? :D
(http://www.freeweb.hu/bithunter/images/coll_genlock.jpg)
But if you are using the VIC, you have to be running at 1mhz and that will pretty much make gaming on the VDC useless. :(
Why would it be useless? There are plenty of good games on the C64 running at 1MHz. Most of them I can't keep up with at that speed, much less twice as fast! :)
Though you couldn't run at 2 MHz, at least you'd have sprites on a hi-res VDC screen.
Because getting graphics data INTO the VDC is slow, even at 2mhz with the VIC turned off; I would imagine it would be needlessly slow with the VIC turned on. So, what specifically would it buy you to be able to genlock VIC and VDC together? I could possibly see a use of 80-column text with VIC multi-color images, but nothing that screams for a need for sprites.
Having said that, I'm sure some demo makers would LOVE to have this capability....
It's the standard answer, Payton: "Because it is there!" :)
And remember, you CAN switch on FAST mode during the horizontal and vertical refresh for about a 20% speed boost. So all is not lost.
Quote from: plbyrdBecause getting graphics data INTO the VDC is slow, even at 2mhz with the VIC turned off; I would imagine it would be needlessly slow with the VIC turned on.
2Mhz with the VIC turned off does increase performance some, but not enough to make up for the VDC itself. For anything more complex than block copy or fill, a graphically intensive program will spend so much time dealing with the VDC that any performance advantage of 2Mhz processor speed is lost. Where the VDC shines is its resolution, its excellent and easy scrolling capabilities, and quickly moving around blocks to whole byte boundaries. Being able to combine those advantages with hardware sprites would compensate for having to work in 1Mhz mode, as well as being much more pleasurable to program for.
That said, more realistically I expect that most methods of enhancing the 128's graphics capabilities, short of pure genius like Hydrophilic's interlace hack, would be too complex and too expensive to be practical.
However, maybe something like this (http://jledger.proboards19.com/index.cgi?board=microhacking&action=display&thread=1174784082) would be suitable? Seems it would be less expensive and require less complicated hacking to get a 128 controlling it.
Quote from: nikonikoQuote from: airship(4) Could you add a little daughter board - something like CLD's 64k video RAM expander - to enhance the VDC or VIC video capabilities? Like with the luminance thing above, or to add more available scanlines, or more pixels per line, or MORE COLORS (especially more colors), etc.
The second version of the Graphic Booster 128 (http://www.c128.net/infos/gb128info.htm) was advertised as allowing 7200 out of 65000 colors at once.
The first version, as far as I can tell, was just a 64K VDC upgrade coupled with new BASIC commands for VDC programming. The ads claimed, though, that you could choose 2 colors out of 3000 in graphics mode or 16 colors out of 2000 in text mode. Seems doubtful to me, because after the 128 DCR came out with 64K VDC RAM standard, the Graphic Booster was rereleased as a simple ROM plus disk, and then simply a disk version with no ROM. So where were the extra colors coming from if special hardware wasn't needed?
The (theoretical) high number of possible colours on the screen is accessible via the fade-parameter and different patterns (mixing of the possible four colors: background / foreground for each of the two interlaced raster lines per color block). The colors are not the colour of one pixel! It is only the overall visual impression.
Fading (fade-parameter) is very strange. I think it is something like the hozizontal (de-)adjustment of a monitor with the h-sync poti. So you will "fade" the colour of the whole screen (by manipulation of one or some VDC register(s)). I didn't ever recognize this effect on a monitor. It is hardware depending may be it will work on a 1901 but not in VICE and not on a 1084.
The (software) difference between V1 and V2 of the Graphic Booster is the "optimization" of pattern-mixing / fading. The version avaliable on C128.net is V2 [evidence: the manual explains how to upgrade V1 programs to V2].
Regards WTE
A 64/128 Genlock. That's sooooo cool. I thought that was vaporware. With that you have a lot of posibilities. Like use the VDC for static/scrollable background, and use the VIC for sprites and background enhancment. The biggest downside would be the Genlock only works on composite (just a guess!) so you'd have to use the VDC monochrome :(
I really liked nikoniko's idea for extra colors from the VDC (I always assumed it would output to VGA) but I was doing some unrelated programming last night and it hit me like a ton of bricks: the VDC output is only sync and colors so there is no way to detect which color is 'background' and which is 'foreground' :( Well you could if you used only text mode. Since the background is the same everywhere you could determing the background in an off-screen location, like a few rasters after v-sync.
Quote from: nikonikoHowever, maybe something like this would be suitable? Seems it would be less expensive and require less complicated hacking to get a 128 controlling it.
Oooh. Another video controller. Take multi-monitor apps to the 3rd degree :)
Quote from: wteFading (fade-parameter) is very strange. I think it is something like the hozizontal (de-)adjustment of a monitor with the h-sync poti.
I need to check into this VDC 'fade-parameter'. I have no idea what that means...
Quote from: hydrophilicI really liked nikoniko's idea for extra colors from the VDC (I always assumed it would output to VGA) but I was doing some unrelated programming last night and it hit me like a ton of bricks: the VDC output is only sync and colors so there is no way to detect which color is 'background' and which is 'foreground' :(
Ah... you probably didn't see the update I had made to my earlier post to clarify the technique. The method doesn't need to know which color is background or foreground. You simply take 2/3 color of the first pixel and 1/3 of the second. That's it. I only used the words 'background' and 'foreground' out of habit. Regardless, seems the method wouldn't work unless you converted the signal to some other form such as analog RGB. :(
Quote from: airshipMaybe we could start with one of these? :D
Ah, I missed your nice picture there when I viewed the thread earlier. I didn't know there were any genlocks made with C64/128 in mind. Does the included software let you do titling?
I have absolutely no idea. I found that pic on the Hungarian web site where the picture is hosted, which by the way has pictures of LOTS of cool C64 hardware, much of it unseen on this side of the pond. Just click on all the buttons and links. Every one seems to lead to new 8-bit magic.
http://www.freeweb.hu/bithunter/
The C64/128 genlock was an absolute shocker to me. I'd never heard of it. But, of course, now I want one so bad my eyes are all bugged out and my hands are furiously throwing money at the screen hoping one will magically appear. Hey, it works with eBay!
My research only shows that Scanntronik now make "high-quality data loggers", though in the past they made several C64-related video products, including video digitizers. Most of them are pictured on the Hungarian site above somewhere. Fortunately, the product names are generally in recognizable English, even if the descriptive text is not.
EDIT: Wow! On this page: http://www.freeweb.hu/bithunter/ he's got the driver disks for many of his hardware items! If you've got a piece of hardware and are missing the disk, check here.
Quote from: niknikoThe method doesn't need to know which color is background or foreground. You simply take 2/3 color of the first pixel and 1/3 of the second. That's it. I only used the words 'background' and 'foreground' out of habit.
That's a relief: there is still hope!
Quote from: nikonikoRegardless, seems the method wouldn't work unless you converted the signal to some other form such as analog RGB.
Analog RGB is a good idea if you have a 1902 or 1084 monitor. I was thinking for digital RGB, you could use pulse-width modulation. This assumes the monitor (or cable!) won't filter out hi-frequencies (16 * 3 = 48MHz).
Quote from: hydrophilicA 64/128 Genlock. That's sooooo cool. I thought that was vaporware.
Hmm, I wonder how the Scantronnik compares with my Comgen 64.
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
Quote from: hydrophilicI was thinking for digital RGB, you could use pulse-width modulation. This assumes the monitor (or cable!) won't filter out hi-frequencies (16 * 3 = 48MHz).
That's an idea. I wonder if it would work.
Also I'm thinking I may have been too quick to throw out the idea of using composite instead of RGBI, or in addition to it. Having a display with many different shades of grey would actually be very nice. I've always been partial to greyscale myself.
New idea:
How about using double-buffering to get 256 different colors? Switch buffers every video frame. If a pixel in the first buffer has one color, and the same pixel in the second buffer has the same color, you'd get that color. BUT if the first and second buffers each had different colors, you'd get a visual mix of both. There'd probably be a little flicker, but not anything near as bad as doing hi-res by interlacing two offset frames. You'd be interlacing for color mixes, not resolution.
Interesting you should mention that. I checked the documentation for the C128 Graphic Booster. I still am not 100% what is going, but from what I read, it is doing both spatial dithering (two pixels side by side blend for 'new' color) and temporal dithering (different color on alternate frames) with both methods you can get the claimed 65000 colors.
If VIC FLI is any indication, the flicker is not too bad assuming you choose color pairs wisely. Of course the 'problem' is highly dependant on the particular monitor, lighting environment, and user perception.
But you are talking about using a device with a frame buffer? That would be quite a project! In this case, I don't think there would be any flicker since the device would output a constant color on every frame (although it would take two frames to build the image).
On the same lines, the device could also combine two rasters from a VDC interlace screen and produce a non-interlaced output with more colors. You would get a LOT of colors combining these methods (horizontal/pixel combination, vertical/interlace combination, and temporal/frame combination).
Sounds like something I would actually pay for...
Edit
Silly me. Vertical/interlace combination is equivalant to temporal/frame combination, unless we use 4 frames to produce an output image. That would limit output to 15fps NTSC (or 12.5fps PAL) but since the VDC is so slow anyway, this might be practical?
Quote from: airshipHow about using double-buffering to get 256 different colors? Switch buffers every video frame.
I've tried that in VICE before, and it's acceptable as long as there isn't too much contrast between the first frame and the second. (Eg. Don't try to mix white and black). On a real 128 and appropriate monitor, the effect should be even better since (I think) the phosphors would have a bit more persistence(?).
Hmm... if my very rusty math is right, then n items, taken r at a time, with order being unimportant and no repetitions allowed, gives us
n!
---------- combinations
r!(n - r)!
For 16 colors mixed over two frames gives us 120 possible colors. That would be reduced by some combinations being too flickery to be useful, but I imagine that would probably still leave at least 60 decent colors if not more. It might not be 256, but hey, it's still better than 16. :)
I'm counting on both phosphor delay and persistence of vision. Between the two, it ought to look just fine.
Hadn't thought about the whole luminance issue. While colors that are far apart WOULD blend, they'd flicker more and look crappy. Closer colors should work better. I was initially thinking that yellow/white would make a nice light yellow, dark red/light red would make for a medium red, etc. But it would be interesting to see how far you could stretch it.
If I remember what Bil Herd has said on the C64 color palette, most of the colors are diametrically opposed pairs. There's a site somewhere with a color wheel that would show which were closest, and therefore would blend best.
And I hadn't thought of using temporal and spatial dithering together. Though slow, it might work okay for static images.
Hmm... I wonder how bad it would look to do two frames with one set of color attributes, followed by one frame of a different set. Lather, rinse, repeat. If human vision would accept it, that would accomplish something similar to the 2/3 + 1/3 mixing I proposed earlier, thus allowing many more colors to be created, but my gut tells me it would look like crap.
I've seen it done with 100Hz refresh on a PC before and it was perfectly fine, but 60Hz and especially 50Hz would almost surely be pushing it too far. :/
I dunno. 60hz makes for really flickery interlace if the contrast is high. But with the screens overlaid on one another, 30fps it might not be too bad, especially with both phosphor and vision persistence working together for you.
Maybe one of you hotshot coders should whip out an assembler? :)
Some code I found on The Fridge (http://www.ffd2.com/fridge/vic/2mhz128.s) that pops the C128 into 2MHz mode when the 40-column display scan is in the border area:
; 2 mhz 40 column 128 mode interrupt routine
; This will enable the 40 column mode of the c128 to run at almost 2MHz!
; The trick is to turn on the 2MHz mode in the borders, and turn on the
; 1MHz mode while in the 40 column screen.
; This also illustrates the technique of interrupt handling and VIC-II
; massaging by handling the raster interrupts.
; By Todd S. Elliott
; Equates
iirq = $0314; IRQ Vector for interrupt handling
mmucr = $FF00; MMU Configuration Register
vicirq = $D019; VIC-II Interrupt Register
raster = $D012; Raster compare register
clkrat = $D030; Adjusts the speed of the 8502 chip
crti = $ff33; Common interrupt return vector
; set up the irq routine
two'mhz sei
lda sta iirq
lda >twomhz
sta iirq+1
cli
rts
; the irq routine to handle the 2 mhz speed output
twomhz lda #$00:sta mmucr; switch to bank 15 first
cld; required by irq routine
lda #$01
sta vicirq; prevent normal raster clear-interrupt
lda raster
cmp #248; check to see which scanline we're at
bcc +
ldy #$05
- nop; a little timing tweak to finesse the raster interrupt
dey; (NTSC timing)
bne -
lda #49
sta raster
lda #$01
sta clkrat; turn on 2 mhz mode
bne ++
+ lda #$00
sta clkrat; switch back to 1 mhz mode
lda #249
sta raster; store in bottom scanline
jsr $f5f8; update timer
lda $dc0d; clear CIA interrupts
jsr $ff9f; check keypress
+ jmp crti; return to normal irq exit routine
; end of 2 mhz routine