Atari v Commodore

[andym00]

You could in theory use a spare PADDLEx register, and if the POTGO sequence was started during VBlank at an exact known time, use that to help with syncing.

 

The thing is... you have WSync, which in 98% of cases gives the HALT until near enough the exact spot you need.

 

In the other 2%, e.g. if you had a narrow-screen situation like NRV is using with "Project M", the 6 cycles or so of jitter doesn't really matter since you can just have the Timer occur such that your screen changes would coincide to an offscreen area.

 

 

You can also use POTGO in Fast mode, which in effect turns the PADDLEx registers into cycle counters, although it's only good for 2 scanlines.

 

But if you want an IRQ every 2 lines at some cycle accurate (& stable) position across the line, and without burning all the CPU sitting in WSYNCs 95% of the time it's useful..

 

Fast mode is a good idea actually Can it be retriggered multiple times per frame or does it need time between reseting? That's actually a bloody nice idea though

The only way I could think of before you mentioned that was to trigger the lightpen and read the lightpen horizontal position back from it..

 

It's something that's been on my mind recently, but not wanting to burn cycles sitting in a display kernel and there didn't seem to be a suitable solution to the jitter, but the fast mode is good, if it can be retriggered multiply over the frame which I doubt somehow, but I look forward to being surprised

Edited September 25, 2009 by andym00

[emkay]

Is it even possible to generate absolutely cycle stable IRQs on the A8 ? Without using double-irq techniques ?

STA WSYNC

 

That's the answer I was expecting from Emkay..

I meant at any chosen cycle.. With a timer source, that isn't related to the scanline position, I meant is there a way to read and fixup cycles based upon some modulo count of elapsed cycles ? Any source available to allow some correction for interrupt jitter.. That doesn't involve WSYNC and burning clock cycles like they're going out of fashion..

 

 

This is so nuts. You should search for a couch doctor or else... WSYNC is far more suitable for dispplay stuff you even could consider... the scanline position is ALL that is needed to be correct.

Well, I don't know how exactly the racing game is done. But it's a fact that it's horizontal resolution is reduced. Possibly it is using Sprites for the background. But it -by far- does less on the screen than Dimension X.

[andym00]

This is so nuts. You should search for a couch doctor or else... WSYNC is far more suitable for dispplay stuff you even could consider... the scanline position is ALL that is needed to be correct.

The only nuts here are those inside your skull.. When you actually understand why there might be a use for cycle-accurate, jitter-free, mid-line interrupts that don't waste all the cpu sitting on WSYNC, then we can talk.. Until then, adios..

[emkay]

I love how when there's more colours you side-step to "oh, less resoultion", but unfortunately you're wrong there as wel..

 

Look again:

 

 

 

One gamescreen has the resolution of 288x64 .... 288 is less than 320. So, who is wrong?

 

 

C64 seems not even to be able to show two vehicles in one screen.

[andym00]

Actually, you're right on that.. 288 it is.. Though not surprising really given that that's 7 sprites wide

Anyway, I'm wrong

[emkay]

This is so nuts. You should search for a couch doctor or else... WSYNC is far more suitable for dispplay stuff you even could consider... the scanline position is ALL that is needed to be correct.

The only nuts here are those inside your skull.. When you actually understand why there might be a use for cycle-accurate, jitter-free, mid-line interrupts that don't waste all the cpu sitting on WSYNC, then we can talk.. Until then, adios..

 

 

Yeah, please , go to the Northpole and get lost.

People like you never understand that your jitter free midline interrupts are useless on other computers than the C64...

The colours of the Atari are clearly colour clock depending, and for this resolution we have more than one solution to have cycle exact colour changes at the needed line positions.

 

At least you should push that nail that fixes your brain to the hires spot of the C64.

The Drag Mark around that gets black and the heat of your shoes seem to reach your head...

[analmux]

But if you want an IRQ every 2 lines at some cycle accurate (& stable) position across the line, and without burning all the CPU sitting in WSYNCs 95% of the time it's useful..

Well, a quick thought on this would be to use maybe 2 timers instead. The jitter is mainly caused by uncertainty in number of cycles used for the last instruction executed before the IRQ. This can be from 2 up to 6 (or 7) cycles.

 

We can do this by using f.e. 2 pokey channels. 1 channel at 15khz and another at 1.79mhz baseclock.

The 2nd timer is, say 12 cycles later than the 1st.

 

The 1st is used to balance the timing uncertainty. Do a string of NOP instructions, and wait for next IRQ. ($fffe should be pointed directly to the start of the NOP string). Then the uncertainty for the next interrupt, 12 cycles later is still 1 or 2 cycles.

 

So, I think there's a way to at least reduce the uncertainty to 1 or 2 cycles instead of 1 up to 7.

 

With a little bit of luck it's even possible to do all by just using one timer, redefined by alternating tasks.

[andym00]

People like you never understand that your jitter free midline interrupts are useless on other computers than the C64...

Right, if you say so..

 

The colours of the Atari are clearly colour clock depending, and for this resolution we have more than one solution to have cycle exact colour changes at the needed line positions.

Yes, you have more than one solution, and maybe there's more that you don't realise or comprehend yet.. Ways that are potentially more efficient and ease up the burden on an already over-burdened cpu..

[andym00]

Well, a quick thought on this would be to use maybe 2 timers instead. The jitter is mainly caused by uncertainty in number of cycles used for the last instruction executed before the IRQ. This can be from 2 up to 6 (or 7) cycles.

 

We can do this by using f.e. 2 pokey channels. 1 channel at 15khz and another at 1.79mhz baseclock.

The 2nd timer is, say 12 cycles later than the 1st.

 

The 1st is used to balance the timing uncertainty. Do a string of NOP instructions, and wait for next IRQ. ($fffe should be pointed directly to the start of the NOP string). Then the uncertainty for the next interrupt, 12 cycles later is still 1 or 2 cycles.

 

So, I think there's a way to at least reduce the uncertainty to 1 or 2 cycles instead of 1 up to 7.

 

With a little bit of luck it's even possible to do all by just using one timer, redefined by alternating tasks.

 

I thought about that something like that, it's the same as the double irq method on the 64.. Trigger a raster, clear irqs, and set irq for next line and then nop until irq arrives..

1 or 2 cycles would be better than nothing, at least it narrows the window of re-positioning that's possible.. I think you know what I've been trying

I'll give that a go and see, though I seem to be eating through Pokey timers like they're going out of fashion..

 

And the worst case I think is 9 nine cycles using illegals, but it's not very often you'd use the 9 cycle stuff unless you're trying to break your stable irqs..

 

Ideally it'd be something as simple as this:

IRQ:
    inc $ffff
    nop
    ..

But the reality is there's much more to do.. You need to ack the IRQ as well, which means A needs saving as well, unless there's some magic trick for ack'ing irq on the A8.. Some trick involving RMW instructions and the fact that IRQST is the same address as IRQEN ?

So you'd end up with something like:

      sta zp_a     ; 3
      lda #<.nops  ; 2
      sta $fffe    ; 4
      lda #0       ; 2
      sta IRQEN    ; 4
      lda #xx      ; 2
      sta IRQEN    ; 4 (21)
.nops: 
      nop
      ..

So there's a large overhead (21 cycles + jitter+ irq entry (7 cycles)) on that already, maybe too much to be practical, with a absolute minimum of 30cycles or so just to get into the interrupt.. Which is too much to be practical once you throw in the RTI (and we haven't done anything yet either), unless you let it run for >1 iteration within each interrupt to amortise the irq overheads..

[Rybags]

You don't get jitter-free IRQs (or NMIs for that matter) on either system, or any 6502.

 

The thing is, you need the mechanism to burn cycles such that you have your state of alignment. When you're talking IRQs, you then have to factor in - is all this trickery with Timers, or whatever other mechanisms you employ going to give you any advantages over the tried and true WSync?

 

I should also have added before that you have the VCOUNT Register. Maybe not as useful since it's only 2-line accurate.

But, it is updated at an early time in the scanline (Cycle 8?) as opposed to WSYNC which holds RDY until cycle 105 (104 apparent, since it allows the first cycle of the following instruction).

[andym00]

You don't get jitter-free IRQs (or NMIs for that matter) on either system, or any 6502.

Of course you can't, but with the CIAs you can minimise the cost of cycle stable interrupts very easily.. Point $FFFE at the register just before the CIA timer registers.. Stick a JMP instruction into the register before the timer values with a zero between and you get a jump to a different page depending up your latency/jitter since the timer start counting underflow the moment it elapses, so when the CPU actually fetches the address for the jmp instruction the CIA contains the cycles that have elapsed since the IRQ should have trigged, but was held up by the previous instruction and the initial processing of the irq triggering.. Each delay routine does the appropriate(fixed) delay to align yourself, and it can do useful work on the larger values (>=3 cycles), not just nops etc. to waste time.. The overhead is not so much, which is what makes it a practical solution for many things..

As an example of minimal cost of doing things like that.. So worst case entry is 7 cycles for irq processing.. + up to 9 cycles of instruction latency + 3 cycles of the jmp, of which those 9 cycles of instruction latency can be used effectively (ie: ack th IRQ, save a register or anything that isn't dependent on the cycle timings), so it's pretty damned efficient really..

 

The thing is, you need the mechanism to burn cycles such that you have your state of alignment. When you're talking IRQs, you then have to factor in - is all this trickery with Timers, or whatever other mechanisms you employ going to give you any advantages over the tried and true WSync?

Exactly, and that's what I'm curious about on the A8, if there's anyway to do this efficiently that overall works out cheaper than other ways of doing it that hang off WSYNC.. Not only the raw cost of the code doing stuff, setting registers etc, but also the setup costs for these techniques..

Edited September 25, 2009 by andym00

[analmux]

Then maybe the fastpotscan trick might be a better solution.

 

Once the IRQ is executed, read the fastpotscan register ONE time (it is reset at a fixed position), and do a void/dummy instruction of 1 up to 7 cycles to counter-effect the previous delay.

[TMR]

Hang on, i was talking about games like Red Max and Zybex, you said that a DLI every eight scanlines would balance the colour RAM on the C64 and i questioned how. ...

 

You can stop right there. I said the comparison would be more fair since you are using 40+ cycles to get the additional colors.

 

Which of course the C64 isn't actually doing... For the character based screens used in all but one of the games i mentioned, the badlines fetch screen data in the same way the A8 does for the five colur character-based modes being used, less in fact if the A8 has to fetch more bytes because it's scrolling horizontally. The odd game out from my list as far as the C64 is concerned was BMX Simulator, which runs a bitmapped screen for both versions and the C64 is still only taking that same 40 cycles of DMA every eighth scanline, what is the A8 doing?

 

Sorry, you claimed that GTIA couldn't do 1 color clock scroll. I also mentioned GPRIOR mode 0 so if resolution was important I would have talked about that rather than GTIA scrolling and color re-use.

 

It was an assumption because i'd never seen it done; when you explained how the theory works i accepted it despite no working examples and after that point was concerned with how a game using it would look from amongst other things a design perspective. And again, still a moot point because we were talking character modes and you brought up the GTIA, taking us off at a tangent.

 

Sorry, you specifically stated stands out like a sore thumb and looks wrong. That means ugly if you know your dictionary definitions. You are twisting things ON PURPOSE now rather than playing dumb.

 

Well, i know what the dictionary definitions are because it comes with the job description these days. Dictionaries usually define words rather than phrases though, but lets see... "stands out like a sore thumb", well that's not ugly because merely means that said appendage doesn't fit in with it's surroundings (feel free to hit your own thumb with a hammer, it won't be ugly as such but isn't going to match the one on the other hand). And "looks wrong"... well, if you have a box full of bananas and there's an orange in there, the orange looks wrong but again that's not ugly either.

 

So as for twisting things goes, your accusing me of calling Atari sprites "ugly" when i've obviously done nothing of the sort is far more twisting than anything you claim i'm doing.

 

Chewbacca defense. Take your bullcrap elsewhere. The point is pretty self-explanatory except for those who are emotionally biased and want to twist things into them.

 

And here we go again with that Chewbacca defence garbage... what i posted obviously wasn't a "defense" of any kind, just was outright sarcasm in response to your ridiculous claim. The idea that more colours somehow makes things more beatiful is utter bilge that nobody in their right mind should be believing, let alone expecting anyone else to buy into.

[snicklin]

Lots of UK people don't really know many USA made games, Synapse made many classics for Apple 2, A8, and C64. Or ever played any Sirius classics? eg Blade of Blackpool, Gruds in Space? Or Broderbund? Mask of the sun, The Serpent's Star, The castles of Dr Creep?

 

Absolutely, at the end of the 80's (I got my Atari in '88), the UK market was full of budget titles £1.99/£2.99 from the likes of Atlantis, Players, Mastertronic, Zeppelin etc. Then we got a flood of Eastern European games. As for all those games listed, nah, never played any of them. If I wanted the American games, they were 5x the price on import and a 10yr old kid which I was wasn't going to do that very often. I did have BB though, and that was a fantastic game.

[andym00]

Then maybe the fastpotscan trick might be a better solution.

 

Once the IRQ is executed, read the fastpotscan register ONE time (it is reset at a fixed position), and do a void/dummy instruction of 1 up to 7 cycles to counter-effect the previous delay.

 

I'll give that a go this evening

[atariksi]

Hang on, i was talking about games like Red Max and Zybex, you said that a DLI every eight scanlines would balance the colour RAM on the C64 and i questioned how. ...

 

You can stop right there. I said the comparison would be more fair since you are using 40+ cycles to get the additional colors.

 

Which of course the C64 isn't actually doing... For the character based screens used in all but one of the games i mentioned, the badlines fetch screen data in the same way the A8 does for the five colur character-based modes being used, less in fact if the A8 has to fetch more bytes because it's scrolling horizontally. The odd game out from my list as far as the C64 is concerned was BMX Simulator, which runs a bitmapped screen for both versions and the C64 is still only taking that same 40 cycles of DMA every eighth scanline, what is the A8 doing?

...

Good, if A8 is in a 5-color text mode that has 40+ wasted cycles, then the comparison is more even although it probably needs to burn a few more to really make it fair.

 

Sorry, you claimed that GTIA couldn't do 1 color clock scroll. I also mentioned GPRIOR mode 0 so if resolution was important I would have talked about that rather than GTIA scrolling and color re-use.

 

It was an assumption because i'd never seen it done; when you explained how the theory works i accepted it despite no working examples and after that point was concerned with how a game using it would look from amongst other things a design perspective. And again, still a moot point because we were talking character modes and you brought up the GTIA, taking us off at a tangent.

You yourself was doubting and now you are blaming me for going off tangent. I can talk about GTIA or GPRIOR 0 easily.

 

Sorry, you specifically stated stands out like a sore thumb and looks wrong. That means ugly if you know your dictionary definitions. You are twisting things ON PURPOSE now rather than playing dumb.

 

Well, i know what the dictionary definitions are because it comes with the job description these days. Dictionaries usually define words rather than phrases though, but lets see... "stands out like a sore thumb", well that's not ugly because merely means that said appendage doesn't fit in with it's surroundings (feel free to hit your own thumb with a hammer, it won't be ugly as such but isn't going to match the one on the other hand). And "looks wrong"... well, if you have a box full of bananas and there's an orange in there, the orange looks wrong but again that's not ugly either.

 

So as for twisting things goes, your accusing me of calling Atari sprites "ugly" when i've obviously done nothing of the sort is far more twisting than anything you claim i'm doing.

No, it's also constituting ugly in your interpretation as well. And to back that up-- you gave your Chewbacca Defense example later.

 

Chewbacca defense. Take your bullcrap elsewhere. The point is pretty self-explanatory except for those who are emotionally biased and want to twist things into them.

 

And here we go again with that Chewbacca defence garbage...

It's not AGAIN. It *IS* Chewbacca defense and everytime I stated it before it *WAS* Chewbacca defense.

 

what i posted obviously wasn't a "defense" of any kind, just was outright sarcasm in response to your ridiculous claim. The idea that more colours somehow makes things more beatiful is utter bilge that nobody in their right mind should be believing, let alone expecting anyone else to buy into.

 

Your example is Chewbacca defense. More colors and more shades does make things more beautiful even in your example. You can have a beautiful garbage can or carcass with more colors/shades and an ugly one if you just had purple, yellow, and orange. Your example does not refute that having more colors/shades available does make the objects more beautiful. It's just to confuse people and mislead people just like your claim above about "utter bilge".

[atariksi]

You don't get jitter-free IRQs (or NMIs for that matter) on either system, or any 6502.

Of course you can't, but with the CIAs you can minimise the cost of cycle stable interrupts very easily.. Point $FFFE at the register just before the CIA timer registers.. Stick a JMP instruction into the register before the timer values with a zero between and you get a jump to a different page depending up your latency/jitter since the timer start counting underflow the moment it elapses, so when the CPU actually fetches the address for the jmp instruction the CIA contains the cycles that have elapsed since the IRQ should have trigged, but was held up by the previous instruction and the initial processing of the irq triggering.. Each delay routine does the appropriate(fixed) delay to align yourself, and it can do useful work on the larger values (>=3 cycles), not just nops etc. to waste time.. The overhead is not so much, which is what makes it a practical solution for many things..

As an example of minimal cost of doing things like that.. So worst case entry is 7 cycles for irq processing.. + up to 9 cycles of instruction latency + 3 cycles of the jmp, of which those 9 cycles of instruction latency can be used effectively (ie: ack th IRQ, save a register or anything that isn't dependent on the cycle timings), so it's pretty damned efficient really..

...

But not as efficient as Atari CPU which can stay in sync-with the beam despite the sprites and color ram accesses. You need to have efficient methods since your BA signal screws things up every so often. Of course, it's a nice trick to use JMP opcode put into the CIA registers.

 

The thing is, you need the mechanism to burn cycles such that you have your state of alignment. When you're talking IRQs, you then have to factor in - is all this trickery with Timers, or whatever other mechanisms you employ going to give you any advantages over the tried and true WSync?

Exactly, and that's what I'm curious about on the A8, if there's anyway to do this efficiently that overall works out cheaper than other ways of doing it that hang off WSYNC.. Not only the raw cost of the code doing stuff, setting registers etc, but also the setup costs for these techniques..

 

Several times IRQ example was posted in this thread that keeps in sync with the video beam with ZERO overhead. You can't get any more efficient than that. Only Amiga is the only other system I know that can do it with ZERO overhead. If it's once in a while, WSYNC is perfectly okay. If it's at a higher frequency, it's better to just keep things cycle exact. Of course, at the higher frequency you also have the fast pot scan to read back as already mentioned.

[atariksi]

You don't get jitter-free IRQs (or NMIs for that matter) on either system, or any 6502.

...

Normally, you don't but you can have stable DLIs, VBIs, and IRQs if background code is written in cycle-exact manner.

 

I should also have added before that you have the VCOUNT Register. Maybe not as useful since it's only 2-line accurate.

But, it is updated at an early time in the scanline (Cycle 8?) as opposed to WSYNC which holds RDY until cycle 105 (104 apparent, since it allows the first cycle of the following instruction).

VCount updated is available on 8th cycle after WSYNC. On 7th cycle after WSYNC, it still has the old value.

[Lazarus]

Several times IRQ example was posted in this thread that keeps in sync with the video beam with ZERO overhead. You can't get any more efficient than that. Only Amiga is the only other system I know that can do it with ZERO overhead. If it's once in a while, WSYNC is perfectly okay. If it's at a higher frequency, it's better to just keep things cycle exact. Of course, at the higher frequency you also have the fast pot scan to read back as already mentioned.

What about the four CIA timers? You can easily sync those to the screen refresh and have 2 IRQs and 2 NMIs at screen positions you want.

[oky2000]

I love how when there's more colours you side-step to "oh, less resoultion", but unfortunately you're wrong there as wel..

 

Look again:

 

 

 

One gamescreen has the resolution of 288x64 .... 288 is less than 320. So, who is wrong?

 

 

C64 seems not even to be able to show two vehicles in one screen.

 

There are only two resolutions on the C64, regardless of how many pixels are being plotted on the screen so it's incorrect to say the resolution is lower...maybe less of the screen used is more accurate way of saying things perhaps?

[andym00]

But not as efficient as Atari CPU which can stay in sync-with the beam despite the sprites and color ram accesses. You need to have efficient methods since your BA signal screws things up every so often. Of course, it's a nice trick to use JMP opcode put into the CIA registers.

 

I know what you mean, but lets just use an example on a software sprite heavy scenario where most of the time is going into actual computation for a player multiplexor and the drawing of software sprites rather than hand feeding the diisplay.. With the exception of a few (say 28) DLIs, it would be more efficient to interrupt (if the overhead was low enough) repeatedly for (say) 16 lines without having to have the DLI sit looping on WSYNC to achieve the same thing, whilst the main code underneath is being starved of cycles..

 

I'd rather lose 16 lines of 40 cycles to doing this via a stable interrupt, than lose 16 lines of WSYNC baby sitting, or end up with an absolute rats nest of code to try and do useful things in the time after hitting WSYNC over those 16 lines in the delay time, most of which will be WSYNC then do a delay to get to the right cycle.. Maybe in a demo where everything hangs together cycle for cycle, but in a game scenario where there's chuff load more happening than just some DLIs.. I could use all the time wasted in those delay outside the interrupt..

 

And the cycle exact options, when the cycle counts are variable are just totally unfeasible, outside of a demo.. In my opinion..

 

Either way, swings and roundabouts.. I'm just curious to explore the avenues available to me on this machine.. And someone essentially saying 'that's not how we do it round these parts boy' without any explanation as for why achieves nothing bar rubbing me up the wrong way

edit: and that's not aimed at you by the way..

 

Several times IRQ example was posted in this thread that keeps in sync with the video beam with ZERO overhead. You can't get any more efficient than that. Only Amiga is the only other system I know that can do it with ZERO overhead. If it's once in a while, WSYNC is perfectly okay. If it's at a higher frequency, it's better to just keep things cycle exact. Of course, at the higher frequency you also have the fast pot scan to read back as already mentioned.

 

Cycle exact and losing a large chunk of the cpu in the displayed portion is great, but not everything can afford that since it's got other things to do, maybe not everything is trying to conform to the standards of what is considered to be A8-normal

Edited September 25, 2009 by andym00

[andym00]

Normally, you don't but you can have stable DLIs, VBIs, and IRQs if background code is written in cycle-exact manner.

 

Doesn't have to be cycle-exact code, only an *odd* number of cycles for your interrupt code if the CPU is running nothing but NOPs outside of the IRQ

[atariksi]

Several times IRQ example was posted in this thread that keeps in sync with the video beam with ZERO overhead. You can't get any more efficient than that. Only Amiga is the only other system I know that can do it with ZERO overhead. If it's once in a while, WSYNC is perfectly okay. If it's at a higher frequency, it's better to just keep things cycle exact. Of course, at the higher frequency you also have the fast pot scan to read back as already mentioned.

What about the four CIA timers? You can easily sync those to the screen refresh and have 2 IRQs and 2 NMIs at screen positions you want.

 

Yeah, you can sync up to VBlank but then how do you keep that sync given the BA cycles throw off the cycles you are counting on the code. See my example posted in my next message.

[Bryan]

Sorry, you claimed that GTIA couldn't do 1 color clock scroll. I also mentioned GPRIOR mode 0 so if resolution was important I would have talked about that rather than GTIA scrolling and color re-use.

 

It was an assumption because i'd never seen it done; when you explained how the theory works i accepted it despite no working examples and after that point was concerned with how a game using it would look from amongst other things a design perspective. And again, still a moot point because we were talking character modes and you brought up the GTIA, taking us off at a tangent.

I'm not sure how a 1 color clock scroll (160 pixel) would be possible in a GTIA mode. The scroll register is in Antic which will simply delay the data to GTIA by however many cycles. GTIA doesn't know the data is delayed, so you should simply get a corrupted screen for all odd settings of HSCROL.

 

How can you actually move the pixel borders except by switching between modes 9 and 10? A long time ago I came up with a picture viewer that shifted a mode 9 screen by a half-pixel every frame but then I discovered it didn't work on other machines (heating the GTIA sometimes worked, though).

Edited September 25, 2009 by Bryan

[atariksi]

Normally, you don't but you can have stable DLIs, VBIs, and IRQs if background code is written in cycle-exact manner.

 

Doesn't have to be cycle-exact code, only an *odd* number of cycles for your interrupt code if the CPU is running nothing but NOPs outside of the IRQ

 

Well, the background code has to divide evenly into the cycles remaining for the background task. In the example below of stable VBI (w/o WSYNC), see the idle loop where code is 17 cycles but can also be other factors that divide evenly into cycles remaining.

 

;*** ATVBI.ASM: Makes VBI perfectly stable on Atari 800XL by Krishna Software Inc.

TIMERFREQLSB = 53760

TIMERFREQMSB = 53762

WSYNC = 54282

VCOUNT = 54283

 

DOSVEC = 10

CASINI = 2

WARMSTART = 58484

VMIRQ = 534 ;hardware irq ptr

VBI = 546 ;Vertical Blanking Intr (NMI)

 

ORG = 600h

;DW 0FFFFh

;DW StartAdr

;DW LastOffset-1

DB 0,3 ;# of sectors to load 1..255

DW ORG

DW StartAdr

Rts

StartAdr: Lda #MyReset,L

Sta CASINI

Lda #MyReset,H

Sta CASINI+1

Lda #0

Sta 580

Lda #2

Sta 9

Jmp WARMSTART

MyReset: Lda #2

Sta 9

Lda #MyReset,L

Sta CASINI

Lda #MyReset,H

Sta CASINI+1

Lda #128

Sta 40000

Lda #160

Sta 40080

Lda #65

Sta 40160

Sei

Lda #0 ;no VBIs nor DLIs for maximum performance

Sta 54286

Sta 54287

Sta 53774 ;disable all IRQs

Sta 54272 ;turn off screen

Lda #56

Sta 54018 ;set direction ctrl for 54016

Lda #255 ;set all pins for output

Sta 54016

Lda #60

Sta 54018 ;set data register at 54016

Lda #254 ;output zero on bit 0 (Pin 1)

Sta 54016

Lda #TimerTwoIRQ,L ;general IRQ routine but we use only for timer #2

Sta VMIRQ

Lda #TimerTwoIRQ,H

Sta VMIRQ+1

Lda #MyVBI,L

Sta VBI

Lda #MyVBI,H

Sta VBI+1

;Lda #80 ;40 for join channels 3,4; +80 for channels 1+2 @1.79Mhz

Lda #1+40 ;0 for 63Khz timers using 8-bit divisors (1 for 15.7Khz)

;+16 for 16-bit divisor on ch.1+2

Sta 53768

Lda #165 ;lsb 172-7 for 60Hz (86-7 for 120Hz) [5,1 for 262 scanlines @15.7Khz]

Sta 53764 ;timer #2 freq = 1789790/[A+7] or 15980/[A+1]

Lda #116 ;msb for rate divisor A (58 for 120Hz, 116 for 60Hz)

Sta 53766

Lda #0 ;disable IRQs for now

Sta 53774 ;enable/disable IRQs

Lda #12

FindEOS: Cmp VCOUNT

Bne FindEOS

Lda #1 ;was 123

FindVBITrigger: Cmp VCOUNT

Bne FindVBITrigger

Sta WSYNC

Nop

Nop

Sta WSYNC

Lda #64

Sta 54286 ;enable VBI

;Jmp Do3Cycle ;inhibits VBI at cycle 7,8,9 after WSYNC/STIMER (on XL)

Do3Cycle: ;Nop

;Nop

;CLI

;Sta 53769 ;start timer counter

;CLI

;Lda #34

;Sta 54272

IdleLoop: ;put your code here (using divisibility by 17)

Lda 0

Lda 1

Lda 2

Lda 3

;Lda 4

Nop

;Jmp NextLbl

NextLbl: Jmp IdleLoop

 

;*** There's a 2 cycle difference between old OS like on Atari 800 and 800XL OS. There's no CLD instruction

;*** on older OSes before vectoring through [534].

TimerTwoIRQ: Pha

;Lda VCOUNT

ChgColor: Lda #15

Sta 53274 ;change register (like color for example)

Lda #0

Sta 53774

Lda #4

Sta 53774

Inc ChgColor+1

;Lda #96

;Sta 53274 ;change register (like color for example)

Pla

Rti

 

MyVBI: ;following is experiment with vbi cycle exactness (OS uses 31 cycles before our routine

;gets control. Our exit procedure is 22 cycles and vectoring uses some. This

;VBI is 14+4*(256*9-1) cycles = 9226 + 2358 refresh cycles + 60 cycle overhead.

;29868-11644 = 18224 cycles left for background (align to 67*17*16).

Lda #255

Sta 54016 ;output "1" in pin 1 on Left Joystick for VBI started

Ldx #0

NxtX: Stx 53274

Dex

Bne NxtX

NxtX2: Stx 53274

Dex

Bne NxtX2

NxtX3: Stx 53274

Dex

Bne NxtX3

NxtX4: Stx 53274

Dex

Bne NxtX4

Lda #254 ;output "0" on pin 1 for end of VBI (for now one scanline time)

Sta 54016

 

 

Pla ;reverse stack from OS VBI entry (4 cycles)

Tay ;$A8 ;2 cycles

Pla ;$68 ;4 cycles

Tax ;$AA ;2 cycles

Pla ;4 cycles

Rti ;6 cycles

 

;LastOffset: DW 2e0h,2e1h,ORG