POKE for fast mode?

[xlar54]

Anyone know the POKE for switching to fast mode?

[xlar54]

Oops, sorry...found it under this thread:

http://landover.no-ip.com/128/viewtopic.php?id=55

   LDA #$01
   sta $d030

Odd thing is... VICE doesnt seem to turn off the VIC-II screen. But it is faster, no doubt.

[BigDumbDinosaur]

Anyone know the POKE for switching to fast mode?

What's wrong with using the FAST command?

[xlar54]

Oh, this is in regards to that editor Im working on... so really Im looking for the ML equivalent... asking for the POKE was just easier.  And thanks Nikoniko - will take care of the VIC also.

[BigDumbDinosaur]

Okay, if you are going to do this from M/L, let's do it right.  

Code Select Expand

scroly   = $d011                     ;VIC scroll & control
clkrate  = $d030                     ;VIC clock rate & raster interrupt control
;
fast       lda scroly                   ;current S&C status
            and #%11101111
            sta scroly                   ;turn off 40 col display
            lda clkrate                  ;current CR & RI status
            ora #%00000001
            sta clkrate                  ;set 2 MHz Ø2 clock
            rts
;
slow      lda clkrate                  ;current CR & RI status
            and #%11111110
            sta clkrate                  ;set 1 MHz Ø2 clock
            lda scroly                   ;current S&C status
            ora #%00010000
            sta scroly                   ;turn on 40 col display
            rts
It is bad practice to blindly write into any memory mapped hardware register like those found in the VIC.  Always read the current value, change only the bit(s) that should be changed and then write back the new value.  Also, it's bad practice to hard code memory references into any program.  Do it symbolically, as shown above.

[StyleCHM]

I tried using symbolic names for the registers once, but by then I knew the memory locations so well I just couldnt change to symbols.

[xlar54]

Thanks BD.. (seems rude and counterproductive to my cause, to call you "bigdumb" )  I see your point.. rather than blindly poking that location, I should look closer at the relevant bit to clear or set instead.  Appreciate that.  And I have updated the source with symbolic labels (using the names from the "Mapping" book).  Ill probably move them out into a separate include file also.

[BigDumbDinosaur]

I tried using symbolic names for the registers once, but by then I knew the memory locations so well I just couldnt change to symbols.

What do you mean "you tried using symbolic names?"  What's there to try?  You use them and the assembler does what it's paid to do.  Although I know my way around the C-128 hardware, I don't recall all the memory addresses of the I/O block, let alone zero page and such.  I do, however, remember names.  I know what D2ICR (interrupt control in CIA #2) refers to, but I'll be damned if I can recall the memory address.  That's why I use include files to define that stuff for me.  I *never* hard code the addresses, nor should you.

What you are describing is what has been a long-standing criticism of Commodore programmers, most of whom have no background in large scale development.  Rather than write code in a style that has been generally accepted in the programming community at large (6502 assembly language standards have existed since the processor's inception), Commodore programmers often infuse their creations with bad habits and dubious practices.  Not too surprisingly, a large project ends up being hard to complete and debug, because so many magic numbers and such have been buried in out-of-the-way places.  I won't even help someone debug a program written that way, as I know a huge amount of time will be wasted trying to figure out what in Sam Hill that write to location $D4 is supposed to do.  What the hell is the purpose of $D4?  I might as well debug the raw machine code seen in a monitor -- it won't take any longer.

Also, I have seen many Commodore M/L programs with little or no commenting.  That is just plain stupid!  You might know right now what you are trying to accomplish, since it's all in your head.  However, I guarantee to a year later from now you will be sitting there staring at that uncommented subroutine full of hard coded references, scratching that same head that previously had all the answers, trying to figure out what the devil you were thinking at the time you wrote it.  I comment *everything*, unless the code is so obvious my dog can figure it out (he's smart but not capable of writing software).  I'm able to look at stuff I wrote 20 years ago and immediately understand what is supposed to happen -- BECAUSE I DIDN'T HARD CODE STUFF AND I USED PLENTY OF COMMENTS!

Just because you know the address of BSOUT is $FFD2 doesn't mean you should code JSR $FFD2 in a program.  Use the official labels and let the assembler do what it is designed to do.  A commercial software house would not hire someone who buries addresses and magic numbers into source files.  The sort of code would be difficult to maintain and extend.  Time costs money and no one ever has enough of both.

[BigDumbDinosaur]

Thanks BD.. (seems rude and counterproductive to my cause, to call you "bigdumb" )  I see your point.. rather than blindly poking that location, I should look closer at the relevant bit to clear or set instead.  Appreciate that.  And I have updated the source with symbolic labels (using the names from the "Mapping" book).  Ill probably move them out into a separate include file also.

I'm going to E-mail some stuff to you which might be instructive.  They will come to you in a ZIP file as DOS-compatible text files, which you can open in any reasonable ASCII text editor (e.g., vi on Linux, Notepad in Window$, etc.).  You'll get a clear picture of what I'm describing.