-
Notifications
You must be signed in to change notification settings - Fork 5
/
Copy pathHowtocode5.txt
2176 lines (1577 loc) · 74.2 KB
/
Howtocode5.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
How to write demos that work (Version 5) - 18/3/93
===================================================
(or the Amiga Demo Coders Reference Manual)
Edited by Comrade J/SAE (ex demo maniac)
Co-Editor post vacant (apply by email)
* Please note this is a REPLACEMENT to text files howtocode1.txt
through howtocode4.txt. Sysops, please remove these earlier files
as they contain many mistakes. Thanks in advance...*
Thanks to: Vic Ricker, Grue, Timo Rossi, Jesse Michael, John Derek Muir,
Boerge Noest, Christopher Klaus, Doz/Shining, Andrew Patterson, Walter
Dao, Chris Green, Magnus Timmerby, Patrik Lundquist, Raymond Penners,
the otherwise anonymous [email protected], Matthew Arnold, TGR/Anthrox,
Tero Lehtonen, Carl-Henrik Sk}rstedt (that's how it's spelt via
7-bit ASCII!!), Arno Hollosi, Irmen de Jong and Jonas Matton
for their comments and contributions.
Thanks also to CS who didn't want a credit but I'd like to say
thank you anyway...
Introduction
============
This file has grown somewhat from the file uploaded over
Christmas 1992. I've been very busy over the last two months,
so sorry that I haven't been able to update this sooner.
It started as an angry protest after several new demos I downloaded
refused to work on my 3000, and has ended up as a sort of general
how-to-code type article, with particular emphasis on the Amiga 1200.
Now, as many of you may know, Commodore have not released
hardware information on the AGA chipset, indeed they have said they
will not (as the registers will change in the future). Demo coders
may not be too concerned about what is coming in a year or two,
but IF YOU ARE WRITING COMMERCIAL SOFTWARE you must be.
Chris Green, from Commodore US, asked me to mention the following:
"I'd like it if you acknowledged early in your text that it IS possible
to do quite exciting demos without poking any hardware registers, and
that this can be as interesting as direct hardware access.
amiga.physik.unizh.ch has two AGA demos with source code by me, AABoing
and TMapdemo. These probably seem pretty lame by normal demo standards
as I didn't have time to do any nifty artwork or sound, and each only does
one thing. but they do show the POTENTIAL for OS friendly demos."
I have seen these demos and they are very neat. Currently you
cannot do serious copper tricks with the OS (or can you Chris? I'd
love to see some examples if you can...), for example smooth
gradiated background copperlists or all that fun messing with
bitplane pointers and modulos. But for a lot of things the
Kickstart 3.0 graphics.library is capable of lots. If you are
in desperate need for some hardware trick that the OS can't handle,
let Chris know about it, you never know what might make it into the
next OS version!
Chris mentions QBlit and QBSBlit, interrupt driven blitter access.
These are things that will make games in particular far easier
to write under the OS now.
Chris also says "Note that if I did a 256 color lores screen using this
document, it would run fifty times slower than one created using the OS,
as you haven't figured out enhanced fetch modes yet. A Hires 256 color
screen wouldn't even work."
There are some new additions to the AGA chapter that discuss some of
this problem, but if you want maximum performance from an AGA system,
use the OS.
Remember that on the A1200 chipram has wait-states, while the
32-bit ROM doesn't. So use the ROM routines, some of them run
faster than anything you could possibly write (on a A1200 with
just 2Mb ram).
The only drawback is again documentation. To learn how to code
V39 OS programs you need the V39 includes and autodocs, which
I'm not allowed to include here a) because I've signed an NDA,
and b) because they're massive...
Perhaps, in a later release, I'll give some highlites of V39
programming... Get Chris Green's example code, it's a good
place to start.
Register as a developer with your local Commodore office to get
the autodocs and includes, it's relatively inexpensive (£85 per
year in the UK)
---
Most demos I've seen use similar startup code to that I was using back
in 1988. Hey guys, wake up! The Amiga has changed quite a bit since
then.
So. Here are some tips on what to do and what not to do:
1. RTFM.
========
Read the f'ing manuals. All of them. Borrow them off friends or from
your local public library if you have to.
Read the "General Amiga Development Guidelines" in the dark grey (2.04)
Hardware Reference Manual and follow them TO THE LETTER.
If it says "Leave this bit cleared" then don't set it!
Don't use self-modifying code. A common bit of code I see is:
... in the setup code
move.l $6c.w,old ; Store Level 3 interrupt.
; Naughty... Naughty.
.. at the end of the interrupt
movem.l (sp)+,a0-a6/d0-d7
dc.w $4ef9 ; jmp instruction
old dc.l 0 ; self modifying!!!!
DONT DO THIS!
68020 and above processors with cache enabled often barf at this
piece of code (the cache still contains the JMP 0 instruction
which isn't then altered).
Interrupts should be set up with the AddIntServer(), SetIntVector()
or AddIntHandler() functions. Read the chapter on Interrupts in
the Amiga Rom Kernal Manual: Libraries
2. Proper Copper startup.
=========================
(Please look at the startup example code at the end of this file).
IF you are going to use the copper then this is how you should set it
up. The current workbench view and copper address are stored, and
then the copper enabled. On exit the workbench view is restored.
This guarantees(*) your demo will run on an AGA (Amiga 1200) machine,
even if set into some weird screen mode before running your code.
Otherwise under AGA, the hardware registers can be in some strange states
before your code runs, beware!
The LoadView(NULL) forces the display to a standard, empty position,
flushing the rubbish out of the hardware registers: Note. There is
a bug in the V39 OS on Amiga 1200/4000 and the sprite resolution is
*not* reset, you will have to do this manually if you use sprites
(See below...)
Two WaitTOF() calls are needed after the LoadView to wait for both the
long and short frame copperlists of interlaced displays to finish.
See the bottom of this file for a full, tested, example startup.asm
code, that you can freely use for your own productions.
It has been suggested to me that instead of using the GfxBase gb_ActiView
I should instead use the Intuition ib_ViewLord view. This will work
just as well, but there has been debate as to whether in the future
with retargetable graphics (RTG) this will work in the same way. As the
GfxBase is at a lower level than Intuition, I prefer to access it this
way (but thank's for the suggestion Boerge anyway!). Using gb_ActiView
code should run from non-Workbench environments (for example, being
called from within Amos) too...
* - Nothing is ever guaranteed where Commodore are involved. They
may move the hardware registers into chipram next week :-)
3. Your code won't run from an icon.
====================================
You stick an icon for your new demo (not everyone uses the CLI!) and
it either crashes or doesn't give back all the RAM it uses. Why?
Icon startup needs specific code to reply to the workbench message.
With the excellent Hisoft Devpac assember, all you need to do is add
the line
include "misc/easystart.i"
and it magically works!
For those without Devpac, here is the relevent code:
---------------------------------------------------------
* Include this at the front of your program
* after any other includes
* note that this needs exec/exec_lib.i
IFND EXEC_EXEC_I
include "exec/exec.i"
ENDC
IFND LIBRARIES_DOSEXTENS_I
include "libraries/dosextens.i
ENDC
movem.l d0/a0,-(sp) save initial values
clr.l returnMsg
sub.l a1,a1
move.l 4.w,a6
jsr _LVOFindTask(a6) find us
move.l d0,a4
tst.l pr_CLI(a4)
beq.s fromWorkbench
* we were called from the CLI
movem.l (sp)+,d0/a0 restore regs
bra end_startup and run the user prog
* we were called from the Workbench
fromWorkbench
lea pr_MsgPort(a4),a0
move.l 4.w,a6
jsr _LVOWaitPort(A6) wait for a message
lea pr_MsgPort(a4),a0
jsr _LVOGetMsg(A6) then get it
move.l d0,returnMsg save it for later reply
* do some other stuff here RSN like the command line etc
nop
movem.l (sp)+,d0/a0 restore
end_startup
bsr.s _main call our program
* returns to here with exit code in d0
move.l d0,-(sp) save it
tst.l returnMsg
beq.s exitToDOS if I was a CLI
move.l 4.w,a6
jsr _LVOForbid(a6)
move.l returnMsg(pc),a1
jsr _LVOReplyMsg(a6)
exitToDOS
move.l (sp)+,d0 exit code
rts
* startup code variable
returnMsg dc.l 0
* the program starts here
even
_main
---------------------------------------------------------
4. How do I tell if I'm running on an Amiga 1200/4000?
======================================================
Do *NOT* check library revision numbers, V39 OS can and does
run on standard & ECS chipset machines (This Amiga 3000
is currently running V39).
This code is a much better check for AGA than in the last
issue!!!!!
GFXB_AA_ALICE equ 2
gb_ChipRevBits0 equ $ec
; Call with a6 containing GfxBase from opened graphics.library
btst #GFXB_AA_ALICE,gb_ChipRevBits0(a6)
bne.s is_aa
Chris Green pointed this out to me. He says quite rightly that the
$dff07c register bits mentioned last time may very well change
if the chip design is changed, even for new production models of the
AA chipset. Thanks!
This will not work unless the V39 SetPatch command has been
executed, so forget about Trackloader demos (and I wish you would!
Some of us want to put your demos on our hard disk). Remember you
can use Fast File System and Directory Caching System floppy disks
on the A1200.
The code in the last issue also had major problems when being
run on non ECS machines (without Super Denise or Lisa), as the
register was undefined under the original (A) chipset, and
would return garbage, sometimes triggering a false AGA-present
response.
5. Use Relocatable Code
=======================
If you write demos that run from a fixed address you should be shot.
NEVER EVER DO THIS. It's stupid and completely unnecessary.
Now with so many versions of the OS, different processors, memory
configurations and third party peripherals it's impossible to
say any particular area of ram will be free to just take and
use.
It's not as though allocating ram legally is dificult. If you
can't handle it then perhaps you should give up coding and
take up graphics or something :-)
If you require bitplanes to be on a 64Kb boundary then try the
following (in pseudo-code because I'm still too lazy to write it
in asm for you):
for c=65536 to (top of chip ram) step 65536
if AllocAbs(c,NUMBER_OF_BYTES_YOU_WANT) == TRUE then goto ok:
next c:
print "sorry. No free ram. Close down something and retry demo!"
stop
ok: Run_Outrageous_demo with mem at c
Keep your code in multiple sections. Several small sections are
better than one large section, they will more easily fit in and run
on a system with fragmented memory. Lots of calls across sections
are slower than with a single section, so keep all your relevent
code together. Keep code in a public memory section:
section mycode,code
Keep graphics, copperlists and similar in a chip ram section:
section mydata,data_c
Never use code_f,data_f or bss_f as these will fail on a chipram
only machine.
And one final thing, I think many demo coders have realised this
now, but $C00000 memory does not exist on any production machines
now, so stop using it!!!
6. Don't Crunch demos!
======================
Don't ever use Tetrapack or Bytekiller based packers. They are crap.
Many more demos fall over due to being packed with crap packers than
anything else. If you are spreading your demo by electronic means
(which most people do now, the days of the SAE Demodisks are long
gone!) then assemble your code, and use LHARC to archive it, you
will get better compression with LHARC than with most runtime
packers.
If you *have* to pack your demos, then use Powerpacker 4+, Turbo
Imploder or Titanics Cruncher, which I've had no problems with myself,
although I have heard of problems with some of these on 68040 machines.
If it will decrunch on a 68040 with caches enabled it will probably
work on everything.
(found in the documentation to IMPLODER 4.0)
>** 68040 Cache Coherency **
>
>With the advent of the 68040 processor, programs that diddle with code which is
>subsequently executed will be prone to some problems. I don't mean the usual
>self-modifying code causing the code cached in the data cache to no longer
>be as the algorithm expects. This is something the Imploder never had a
>problem with, indeed the Imploder has always worked fine with anything
>upto and including an 68030.
>
>The reason the 68040 is different is that it has a "copyback" mode. In this
>mode (which WILL be used by people because it increases speed dramatically)
>writes get cached and aren't guaranteed to be written out to main memory
>immediately. Thus 4 subsequent byte writes will require only one longword
>main memory write access. Now you might have heard that the 68040 does
>bus-snooping. The odd thing is that it doesn't snoop the internal cache
>buses!
>
>Thus if you stuff some code into memory and try to execute it, chances are
>some of it will still be in the data cache. The code cache won't know about
>this and won't be notified when it caches from main memory those locations
>which do not yet contain code still to be written out from the data caches.
>This problem is amplified by the absolutely huge size of the caches.
>
>So programs that move code, like the explosion algorithms, need to do a
>cache flush after being done. As of version 4.0, the appended decompression
>algorithms as well as the explode.library flush the cache, but only onder OS
>2.0. The reason for this is that only OS 2.0 has calls for cache-flushing.
>
>This is yet another reason not to distribute imploded programs; they might
>just cross the path of a proud '40 owner still running under 1.3.
>
>It will be interesting to see how many other applications will run into
>trouble once the '40 comes into common use among Amiga owners. The problem
>explained above is something that could not have been easily anticipated
>by developers. It is known that the startup code shipped with certain
>compilers does copy bits of code, so it might very well be a large problem.
Look at some new EXEC-functions to solve this problem:
CacheClearU() and CacheControl()
Both functions are available with Kickstart 2.0 and above.
I strongly disadvise trying to 'protect' code by encrypting
parts of it, it's very easy for your code to fail on >68000 if you
do. What's the point anyway? Lamers will still use Action Replay
to get at your code.
I never learnt anything by disassembling anyones demo. It's far
more dificult to try and understand someone elses (uncommented)
code than to write your own code from scratch.
7. Don't use the K-Seka assembler!
==================================
It's dead and buried. Get a life, get a real assembler. Hisoft Devpac
is probably the best all-round assembler, although I use ArgAsm
which is astonishingly fast. The same goes for hacked versions of
Seka.
Is it any coincidence that almost every piece of really bad
code I see is written with Seka? No, I don't think so :-)
When buying an assembler check the following:
1. That it handles standard CBM style include files without
alteration.
2. That it allows multiple sections
3. That it can create both executable and linkable code
4. 68020+ support is a good idea.
Devpac 3.0 is probably the best all-round assembler at the moment.
People on a tighter budget could do worse than look at the
public domain A68K (It's much better than Seka!). I'd suggest
using Cygnus Ed as your Text Editor.
8. Don't use the hardware unless you have to!
=============================================
This one is aimed particularly at utility authors. I've seen some
*awfully* written utilities, for example (although I don't want
to single them out as there are plenty of others) the Kefrens
IFF converter.
There is NO REASON why this has to have it's own copperlist. A standard
OS-friendly version opening it's own screen works perfectly (I
still use the original SCA IFF-Converter), and multitasks properly.
If you want to write good utilities, learn C.
9. Beware bogus input falling through to Workbench
==================================================
If you keep multitasking enabled and run your own copperlist remember
that any input (mouse clicks, key presses, etc) fall through to the
workbench. The correct way to get around this is to add an input
handler to the IDCMP food chain (see - you *do* have to read the
other manuals!) at a high priority to grab all input events before
workbench/cli can get to them. You can then use this for your
keyboard handler too (no more $bfexxx peeking, PLEASE!!!)
Look at the sourcecode for Protracker for an excellent example of
how to do the job properly. Well done Lars!
10. Have fun!
=============
Too many people out there (particularly the American OS-Lamic
Fundamentalists) try to tell us that you should never program at a hardware
level. If you're programming for fun, ignore them! But try and put
a little thought into how your code will work on other machines,
nothing annoys people more than downloading 400Kb of demo and then
finding it blows up on their machines. I'm not naming any names, but
there are quite a few groups who I have no intention of downloading
their demos again because I know it's a waste of download. With
the launch of the Amiga 1200 you cannot just write for 1.3 Amiga
500's any more.
I'd like to apologise to all Americans for blaming OS-Fundamentalism
on them. I've since heard from *two* American hardware hackers.
:-)
I guess I ought to point out that 90% of my programs are now
fully OS legal, although I am writing an AGA hardware-hacking
demo for the 1200 now... Demo and Source available soon....
As soon as I have finished that I am writing a fully OS AGA demo,
because I HAVE SEEN THE LIGHT! SATAN MADE ME USE THAT HARDWARE
MANUAL. I WILL NEVER POKE A REGISTER AGAIN, or something like
that... As usual full demo *and* source will be uploaded.
If anyone has any ideas of what I should do (and I'd also
appreciate a nice short tracker module...) you know where
to send them...
11. Don't Publish Code you haven't checked!
===========================================
Thanks to Timo Rossi for spotting the stupid bug in my copper
setup routine (using LOFList instead of copinit). Funnily enough
my own setup routine uses the correct copinit code:
Please ignore the original file (howtocode[1|2|3|4].txt) and use this
instead.
12. Copper End
==============
I've remembered where this double copper end comes from:
The ArgAsm assembler has copper macros (CMOVE, CWAIT and CEND)
built in, and the CEND macro deliberately leaves two copper
END instructions, the manual states this is important
for compatibility reasons..
Will whoever pinched my ArgAsm manual please return it? I bet
it was you Alex..
13. Using a 68010 processor
===========================
The 68010 is a direct replacement for the 68000 chip, it can
be fitted to the Amiga 500,500+,1500 and 2000 without any
other alterations (I have been told it will not fit an A600).
The main benefit of the 68010 over the 68000 is the loop cache mode.
Common 3 word loops like:
moveq #50,d0
.lp move.b (a0)+,(a1)+ ; one word
dbra d0,.lp ; two words
are recognised as loops and speed up dramatically on 68010.
14. Using the blitter.
======================
If you are using the blitter in your code and you are leaving the
system intact (as you should) always use the graphics.library
functions OwnBlitter() and DisownBlitter() to take control
of the blitter. Remember to free it for system use, many system
functions (including floppy disk data decoding) use the blitter.
OwnBlitter() does not trash any registers. I guess DisownBlitter()
doesn't either, although Chris may well correct me on this.
Another big mistake I've seen is with blitter/processor timing.
Assuming that a particular routine will be slow enough that a blitter
wait is not needed is silly. Always check for blitter finished, and
wait if you need to.
Don't assume the blitter will always run at the same speed too. Think
about how your code would run if the processor or blitter were running
at 100 times the current speed. As long as you keep this in mind,
you'll be in a better frame of mind for writing compatible code.
Another big source of blitter problems is using the blitter in interrupts.
Most demos do all processing in the interrupt, with only a
.wt btst #6,$bfe001 ; is left mouse button clicked?
bne.s .wt
loop outside of the interrupt. However, some demos do stuff outside the
interrupt too. Warning. If you use blitter in both your interrupt
and your main code, (or for that matter if you use the blitter via the
copper and also in your main code), you may have big problems....
Take this for example:
lea $dff000,a5
move.l GfxBase,a6
jsr _LVOWaitBlit(a6)
move.l #-1,BLTAFWM(a5) ; set FWM and LWM in one go
move.l #source,BLTAPT(a5)
move.l #dest,BLTDPT(a5)
move.w #%100111110000,BLTCON0(a5)
move.w #0,BLTCON1(a5)
move.w #64*height+width/2,BLTSIZE(a5) ; trigger blitter
There is *nothing* stopping an interrupt, or copper, triggering a
blitter operation between the WaitBlit call and
your final BLTSIZE blitter trigger. This can lead to total system blowup.
Code that may, by luck, work on standard speed machines may die horribly
on faster processors due to timing differences causing this type of
problem to occurr.
The safest way to avoid this is to keep all your blitter calls together,
use the copper exclusively, or write a blitter-interrupt routine to
do your blits for you.
Always use the graphics.library WaitBlit() routine for your
end of blitter code. It does not change any registers, takes into
account any revision of blitter chip and any unusual circumstances,
and on an Amiga 1200 will execute faster (because in 32-bit ROM)
than from chipram.
Another thing concerning blitter:
Instead of calculating your LF-bytes all the time you can do this
instead
A EQU %11110000
B EQU %11001100
C EQU %10101010
So when you need an lf-byte you can just type:
move.w #(A!B)&C,d0
15 NTSC
=======
As an European myself, I'm naturally biased agains the inferior video
system, but even though the US & Canada have a relatively minor Amiga
community compared with Europe (Sorry, it's true :-) we should still
help them out, even though they've never done a PAL Video Toaster for
us (sob!).
You have two options.
Firstly, you could write your code only to use the first 200 display
lines, and leave a black border at the bottom. This annoys PAL owners,
who rightly expect things to have a full display. It took long enough
for European games writers to work out that PAL displays were better.
You could write code that automatically checked which system it is
running on and ran the correct code accordingly:
(How to check: Note, this is probably not the officialy supported method,
but so many weird things happen with new monitors on AGA machines that
I prefer this method, it's simpler, and works under any Kickstart)
move.l 4.w,a6 ; execbase
cmp.b #50,PowerSupplyFrequency(a6) ; 531(a6)
beq.s .pal
jmp I'm NTSC (or more accurately, I'm running from 60Hz power)
.pal jmp I'm PAL (or I'm running from 50hz power).
If people have already switched modes to PAL, or if they are running
some weird software like the ICD Flicker Free Video Prefs thingy, then
this completely ignores them, but that serves them right for trying
to be clever :-)
Probably better would be to check VBlankFrequency(a6) [530(a6)]
as well, if both are 60Hz then it's definately a NTSC machine. If
one or more are 50Hz, then it's probably a better idea to run in PAL.
VBlankFrequency can give all sorts of weird things on an AGA
system (DblPal runs at 48Hz, for example).
Chris Green suggests checking GfxBase->DisplayFlags for PAL
rather than what I do above.
Well, If Commodore had fixed the bug in Kickstart 1.3 that
was reported to them while Kickstart 1.2 was in beta (that a
PAL machine, especially with a Genlock, often fails to report
that it is PAL) then I'd use it. They did fix it in 2.0 though
(at last!) along with the "Oh I've got $200000 RAM. I guess that
means the user wants *two* mouse pointers in the PAL area" bug.. :-)
So, for V1.2/1.3 do the PowerSupplyFrequency() check, on 2.04 or
higher use GfxBase->DisplayFlags check as Chris suggests...
Under Kickstart 2.04 or greater, the Display Database can be accessed.
Any program can enquire of the database what type of displays
are available, so for example "I want a 50hz 15Khz PAL screen. Can
I display it on this Amiga?" (Unfortunately it doesn't take
an ASCII string like that, but it's not much more dificult). Of
course many users will have the default monitor installed (PAL or
NTSC) and not realise that they can have extra modes by dragging
the monitor icon into their Monitors drawer, and of course
this doesn't work on Kickstart 1.3 machines.
Now, if you want to force a machine into the other display system
you need some magic pokes: Here you go (beware other bits in
$dff1dc can do nasty things. One bit can reverese the polarity
on the video sync, not to healthy for some monitors I've heard...)
To turn a NTSC system into PAL (50Hz)
move.w #32,$dff1dc ; Magically PAL
To turn a PAL system into NTSC (60Hz)
move.w #0,$dff1dc ; Magically NTSC
Remember: Not all displays can handle both display systems!
Commdore 1084/1084S, Philips 8833/8852 and multisync monitors
will, and very few US TV's will handle PAL signals.
It might be polite for PAL demos to ask NTSC users if they
wish to switch to PAL (by the magic poke) or quit.
16 Programming AGA hardware
===========================
**** WARNING ****
AGA Registers are temporary. They will change. Do not rely
on this documentation. No programs written with this information
can be officially endorsed or supported by Commodore. If this
bothers you then stop reading now.
I've rewritten this again, because of big mistakes, things
that weren't really necessary, and because no-one realy understood
the original. Remember that for most things the OS provides a much
better and easier way to access new screen modes, and the OS
will be compatible with future chipsets, these registers will
change!
Bitplanes:
Set 0 to 7 bitplanes as before in $dff100.
Set 8 bitplanes by setting bit 4 of $dff100, bits 12 to 15 should be zero.
(ooops. Big mistake last time!)
Colour Registers:
There are now 256 colour registers, all accessed through the original
32 registers
AGA works with 8 differents palettes of 32 colors each, re-using
colour registers from $0180 to $01BE.
You can choose the palette you want to access via the bits 13 to 15 of
register $0106
bit 15 | bit 14 | bit 13 | Selected palette
-------+--------+--------+------------------------------
0 | 0 | 0 | Palette 0 (color 0 to 31)
0 | 0 | 1 | Palette 1 (color 32 to 63)
0 | 1 | 0 | Palette 2 (color 64 to 95)
0 | 1 | 1 | Palette 3 (color 96 to 125)
1 | 0 | 0 | Palette 4 (color 128 to 159)
1 | 0 | 1 | Palette 5 (color 160 to 191)
1 | 1 | 0 | Palette 6 (color 192 to 223)
1 | 1 | 1 | Palette 7 (color 224 to 255)
To move a 24-bit colour value into a colour register requires
two writes to the register:
First clear bit 9 of $dff106
Move high nibbles of each colour component to colour registers
Then set bit 9 of $dff106
Move low nibbles of each colour components to colour registers
For example, to change colour zero to the colour $123456
dc.l $01060000
dc.l $01800135
dc.l $01060200
dc.l $01800246
Note: As soon as you start messing with $dff106 forget all your
fancy multi-colours-per-line plasma tricks. The colour only
gets updated at the end of the scanline. Bummer dudes...
Sprites:
To change the resolution of the sprite, just use bit 7 and 6 of
register $0106
bit 7 | bit 6 | Resolution
------+-------+-----------
0 | 0 | Lowres (140ns)
1 | 0 | Hires (70ns)
0 | 1 | Lowres (140ns)
1 | 1 | SuperHires (35ns)
--------------------------
(Now.. 70ns sprites may not be available unless the Interlace bit in
BPLCON0 is set. Don't ask me why....
There appears to be much more to this than just these two bits.
It seems to depend on a lot of different things...)
For 32-bit and 64-bit wide sprites use bit 3 and 2 of register $01FC
Sprite format (in particular the control words) vary for each width.
bit 3 | bit 2 | Wide | Control Words
------+-------+-------------+----------------------------------
0 | 0 | 16 pixels | 2 words (normal)
1 | 0 | 32 pixels | 2 longwords
0 | 1 | 32 pixels | 2 longwords
1 | 1 | 64 pixels | 2 double long words (4 longwords)
---------------------------------------------------------------
Wider sprites are not available under all conditions.
It is possible to choose the color palette of the sprite.
This is done with bits 7 and 4 of register $010C.
bit 7 | bit 6 | bit 5 | bit 4 | Starting color of the sprite's palette
------+-------+-------+-------+------------------------------------------
0 | 0 | 0 | 0 | $0180/palette 0 (coulor 0)
0 | 0 | 0 | 1 | $01A0/palette 0 (color 15)
0 | 0 | 1 | 0 | $0180/palette 1 (color 31)
0 | 0 | 1 | 1 | $01A0/palette 1 (color 47)
0 | 1 | 0 | 0 | $0180/palette 2 (color 63)
0 | 1 | 0 | 1 | $01A0/palette 2 (color 79)
0 | 1 | 1 | 0 | $0180/palette 3 (color 95)
0 | 1 | 1 | 1 | $01A0/palette 3 (color 111)
1 | 0 | 0 | 0 | $0180/palette 4 (color 127)
1 | 0 | 0 | 1 | $01A0/palette 4 (color 143)
1 | 0 | 1 | 0 | $0180/palette 5 (color 159)
1 | 0 | 1 | 1 | $01A0/palette 5 (color 175)
1 | 1 | 0 | 0 | $0180/palette 6 (color 191)
1 | 1 | 0 | 1 | $01A0/palette 6 (color 207)
1 | 1 | 1 | 0 | $0180/palette 7 (color 223)
1 | 1 | 1 | 1 | $01A0/palette 7 (color 239)
-------------------------------------------------------------------------
Bitplanes, sprites and copperlists should be 64-bit aligned
under AGA. Bitplanes should also only be multiples of 64-bits
wide, so if you want an extra area on the side of your screen for
smooth blitter scrolling it must be *8 bytes* wide, not two as normal.
For example:
CNOP 0,8
sprite incbin "myspritedata"
CNOP 0,8
bitplane incbin "mybitplane"
and so on.
This also raises another problem. You can no longer use
AllocMem() to allocate bitplane/sprite memory directly.
Either use AllocMem(sizeofplanes+8) and calculate how many
bytes you have to skip at the front to give 64-bit alignment
(remember this assumes either you allocate each bitplane
individually or make sure the bitplane size is also an
exact multiple of 64-bits), or you can use the new V39
function AllocBitMap().
17. Keyboard Timings
====================
If you have to read the keyboard by hardware, be very careful
with your timings. Not only do different processor speeds affect
the keyboard timings (for example, in the game F-15 II Strike Eagle
on an Amiga 3000 the key repeat delay is ridiculously short, you
ttyyppee lliikkee tthhiiss aallll tthhee ttiimmee. You use
up an awful lot of Sidewinders very quickly!), but there are differences
between different makes of keyboard, some Amiga 2000's came with
Cherry keyboards, these have small function keys the same
size as normal alphanumeric keys - these keyboards have different
timings to the normal Mitsumi keyboards.
Use an input handler to read the keyboard. The Commodore guys
have spent ages writing code to handle all the different possible
hardware combinations around, why waste time reinventing the wheel?
18. How to break out of never-ending loops
==========================================
Another great tip for Boerge here:
>This is a simple tip I have. I needed to be able to break out of my
>code if I had neverending loops. I also needed to call my exit code when I did
>this. Therefore I could not just exit from the keyboard interrupt which I have
>taken over(along with the rest of the machine). My solution wa to enter
>supervisor mode before I start my program, and if I set the stack back then
>I can do an RTE in the interrupt and just return from the Supervisor() call.
>This is snap'ed from my code:
>
> lea .SupervisorCode,a5
> move.l sp,a4 ;
> move.l (sp),a3 ;
> EXEC Supervisor
> bra ReturnWithOS
>
>.SupervisorCode
> move.l sp,crashstack ; remember SSP
> move.l USP,a7 ; swap USP and SSP
> move.l a3,-(sp) ; push return address on stack
>
>that last was needed because it was a subroutine that RTSes (boy did I have
>porblems working out my crashes before I fixed that)
>Then I have my exit code:
>
>ReturnWithOS
> tst.l crashstack
> beq .nocrash
> move.l crashstack,sp
> clr.l crashstack
> RTE ; return from supervisor mode
>.nocrash
>
>my exit code goes on after this.
>
>This made it possible to escape from an interrupt without having to care
>for what the exception frames look like.
I haven't tried this because my code never crashes. ;-)
19. Version numbers!
====================
Put version numbers in your code. This allows the CLI version command
to determine easily the version of both your source and executable
files. Some directory utilities allow version number checking too (so
you can't accidentally copy a newer version of your source over
an older one, for example). Of course, if you pack your files the
version numbers get hidden. Leaving version numbers unpacked
was going to be added to PowerPacker, but I don't know if this is
done yet.
A version number string is in the format
$VER: howtocode5.txt 5.0 (18.03.92)
^ ^ ^Version number (date is optional)
| |
| | File Name
|
| Identifier
The Version command searches for $VER and prints the string it finds
following it.
For example, adding the line to the begining of your source file
; $VER: MyFunDemo.s 4.0 (01.01.93)
and somewhere in your code
dc.b "$VER: MyFunDemo 4.0 (01.01.93)",0
means if you do VERSION MyFunDemo.s you will get:
MyFunDemo.s 4.0 (01.01.93)
and if you assemble and do Version MyFunDemo, you'll get
MyFunDemo 4.0 (01.01.93)
Try doing version howtocode5.txt and see what you get :-)
This can be very useful for those stupid demo compilations
where everything gets renamed to 1, 2, 3, etc...
Just do version 1 to get the full filename (and real date)
Does this work on Kickstart 1.3? I can't remember, I ditched
my 1.3 Kickstart 2 years ago :-)
20. CDTV
========
I've been asked if there is any special advice on how to program
demos to work on CDTV, and if hardware access to the CDTV (for
playing CD Audio, etc) is possible.
The CDTV is essentially a 1Mb chip ram Amiga with a CD-ROM drive.
The major difference (apart from lack of fast ram or $c00000 ram)
is that the CDTV roms can take up anything from 100-200Kb of ram.
Many demos fail on CDTV through lack of memory.
You can hack your CDTV to switch on/off these roms (put a switch
on JP15), when switched off the CDTV has a full 1Mb of memory and
more software works, but you can still play audio CD's in the CD