NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/4003

Internet Message Format | 1996-08-05 | 10.3 KB

Path: informatik.tu-muenchen.de!fischerj
From: [e-mail] (Juergen "Rally" Fischer)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Demo/game to OS friendly part II
Date: 15 Feb 1996 16:54:48 GMT
Organization: Technische Universitaet Muenchen, Germany
Distribution: world
Message-ID: <4fvogo$[e-mail]>
References: <4e0jhq$[e-mail]> <4e114i$[e-mail]> <4e371l$[e-mail]> <4e3jld$[e-mail]> <4e5k20$[e-mail]> <4e64u7$[e-mail]> <4e9n67$[e-mail]> <4eb61a$[e-mail]> <4ej5du$[e-mail]> <4ejmsc$[e-mail]> <4eqn93$[e-mail]> <4fsjfk$[e-mail]>
NNTP-Posting-Host: hphalle5.informatik.tu-muenchen.de
Originator: [e-mail]


In article <4fsjfk$[e-mail]>,
[e-mail] (Michael van Elst) writes:
|> [e-mail] (Juergen "Rally" Fischer) writes:
|>
|> >which value in gfxbase is that ? what value is it for OCS/ECS blitters ?
|>
|> such questions make this kind of discussion sooooo boring.
naah it's not really a problem.

|>
|> I told you that several times. If you keep forgetting why can't you simply
|> consult the manuals and include files ?

I got autodoks, and they don't explain quite well :\

So I only can guess ;) long *blitter
nooo, that would be too easy. next try.

UBYTE ChipRevBits0 ?
mhm big GFXB_BIG_BLITS, GFXB_HR_AGNUS... bit 0 of the ubyte must be 1 ? :)

mhm but then the fact I can't test for OCS (no GFXB_AGNUS) in this byte
lets me think I'm on the wrong bits...


 BTW next page (wow c0d3r reading RKM :D ), gfxmacros.h,

 #define OFF_VBLANK custom.intena = BITCLR|INTF_VERTB

 was there a shutdown fan writing this page of RKM ?
 I thought we were not to poke...

 they'd better done a #define IFBLITTER and #define CHIPMEMPLANARBITMAP(bm)!

|> That's why FastMem Bitmaps with known structure are most likely not "standard".

known structure ? What is in the Flags of a gfx-card bitmap ?
just displayable, $02 ?

mhm i guess they would have just extended planeptrs to [10] for AAA ?
somehow I got the impression they already could have written
Dpaint-AAA on V1.2 ;) I mean, a Dpaint that'll be able to work in
10 planes on AAA or a emulated 10 planescreen on 24bit screen.

|> The blitter is ECS compatible and acts on _chip memory_. You have full
|> 32bit registers for the DMA channels. There is no restriction to the
|> 0MB..2MB range _in the interface_. There is such a restriction in the
|> current hardware, but this restriction is met if you use pointers to
|> chip memory (as returned by AllocMem and other functions).

I always directly poked that allocmempointers into the dmapointerregs.
or is there a pointer in gfxbase telling where the DMA adress 0 starts
in cpu adress space ? don't shock me! ;)

|>
|> >Aah. so: check for native => planar (that's all, could be in fastmem
|> >or gfx-card vram)
|>
|> To the CPU it wouldn't make any difference where the bitplanes are.

yes. But maybe there could be a bitmap in a DSP-card connetect
via ser: ? ;) cpu wouldn't be able to write to it the conventional
way. Is there a flag telling "non acessable" ? how the bitmaps
look on that A20.. eeh.. tiga card ?


|> >have I interpreted that right...
|>
|> Yes.

phew :)

If ( (bitmap->Flags & BMF_STANDARD) && (gfxbase->ChipRevBits0 &
GFXF_BIG_BLITS) ) printf("yeah a planar ECS blitterable bitmap :)\n");
else printf("Danger! Do not poke.\n");

I'm still wondering about the test for blitter. OCS ?

Can I put this on my homepage ;) or what else to test for to know
I can directly write to a screens bitmap with both blitter+cpu ?

So what if I run a planar mode on a gfxcard but also still got
a AGA-blitter. there seems to be no bit just telling "planar",
bummer. No planar bitmaps on a gfxboard ?

Do writers of gfx-card users define new bits in bitmaps flags
(BMB_CHUNKY or whatever...) ?

Do I have to set the visible flag in a bitmap I pass to openscreen ?
questions...

|> It tells you which chips are present. If you get some address
|> to the custom chips from the system (say in an interrupt server),

why the base adress in the register ?

|> then use that. Otherwise use _Custom = 0xdff000 as the base
|> address.

So my Qblit() function will maybe poke to a different adress
than my OwnBlitter()ed functions. why ?

BTW, brainstorming, do I have to call CMOVE() with $dff180 or with $180 ?
both will work on my A1200...

|> lowlevel.library does nothing like that and it IS part of AmigaOS3.1. It
but not 3.0 ?

|> is used for dumb and unfriendly code that queries the keyboard or joypad.
|> It also gives simple access to a vblank interrupt and timer.
|>
|> So that's for c00l c0d3rz that fail to write working keyboard and interrupt
|> code after 10 years of experience.

;)
but the only OSy way for a paralax scroller (someone told me
about having done it). well, OS3.1...

Having seen some games that do this on A500,V1.2, I must
say for this case: viva copper overtake!

|>
|> What you are thinking of is specialfx.library.

more, a game.library, a multimedia.library :)

ParRead(FILE *,char *,int size);    ;)
                                 ^--------,struct msgport* ??

|>
|> >for adapting to each cpu, and for adapting on a ceratin cpu for each
|> >effect to get optimal framerate (and get cpu needing not more time
|> >than for just copying in moast cases).
|>
|> Obviously you do not want to specify that. The system should chose an optimal
|> method itself (and it might know better than you).

mhm doing cpu+blitter c2p, only measuring helps which combination
(how many cpu passes) are fastest for the effect done.
system would have to call my render functions to find out :)
i.e. AmigaDos would play my game :D

|>
|> >But then the area got to be 4 times smaller to outperform my routine :D
|>
|> *sigh*

sigh but true... I intend to write code for using, not for
nice source code.

|>
|> >but the 3pass c2p needs that special planesetup which needs own
|> >copperlists, which will probably only work on PAL/NTSC.
|>
|> That's why it is pretty unusuable.

but aren't most used configs A1200+1084 ? ;)

And as the new A1200 seems to have 030-40 but still AGA,
and, horrors, maybe no fastmem, the 3pass method is still
usable.


|> >On a card with very fast mem, I would have got a pointer to vram and
|> >the update routine would have done nothing. voila direct render :)
|>
|> And now try the same with a double buffered display and bitmaps that
|> are swapped between virtual memory and graphics card.

well, only windoze would do double-buffering with swapping
the screens from HD :D

No problem though if you got a MMU.


|> >But what if I'm about to write kind of extension, something the
|> >current OS doesn't provide ?
|>
|> That's a rhetorical question. You do not do that. You try to hack around
|> the OS.

Okay, the word "extension" is the problem, right ? ;)

Well, would you see any chance to get the special plane/spritesetup
without "hack around" on OS3.0 ?

You would at least have to bypass CWAIT(). And take care of
all monitor stuff.

Well, it would be nice to have this setup as new type of bitmap
just like a screen opened on a gfx-card.

Writepixarray8() would be patched to 3pass convert if on
ghost-screen.

bitmap->type=BMF_GHOST :D

Well, a clean implementation would need to rewrite all
blt and draw functions...

And somehow you would have to determine if a task opening
a screen is to get a standard bitmap or a ghost-bitmap.
a flag of same class like dualpf or ham.

|>
|> You can synchronize with the screen buffers.
You get a signal when buffer was shown a frame, right ?

|>
|> >What should I use WaitTOF for ?
|>
|> For a simple straight forward synchronization with the display.

That's not what I intend to do.

My current code runs a pri 127 task doing waittof and then writing
into my copperlist to interlace the ghost look. As this is chipset
special anyway, I can turn it into a interupt routine.

If there was the need of kind of "vblank-int" on gfx-cards,
I'd still use the hipri waittofing task. If there is a driver
that busywaits for TOF, my code would be in deep shit.

so far the whole story about me and waittof, which i don't need on
gfxcards anyway.

phew.


|> It is a missing DSKRDY signal. Something that is gracefully handled by the specs
|> (that asks for a 500ms timeout) and that is of course handled by trackdisk.device.
a drive sometimes giving no dskrdy signal ? tackdisk device writing after
0.5 sec anyway ?

|> >Yes, A1200 are incomaptible, my cousins one is that incompatible
|>
|> You are an idiot.

not. You will always find a category that makes 2 identical models
incompatible. At least the different quarzes...

And for the drive story, no problem to use them to get code incompatible.

i=timer
stepdrive
waitfordskrdy
i=timer-i

p=malloc(1024)
for (n=0;n<i;n++)
  *p++=0;

hehe, if dskrdy needs more than 1024 time units then the
code will poke into unallocated memory.

voila incompatible vanilla A1200 ;)

|>
|> >|> It has been clear from the beginning. You do invalid assumptions and as
|> >|> a result your code crashes.
|>
|> >oh it does fine on my Kickstart revision.
|>
|> THAT IS THE PROBLEM. YOU THINK IT WORKS WHEN IT WORKS FOR YOU.

no, you know that in this case it's all different.

|>
|> >As I assume loadview also makes use of copjmp2,
|>
|> Sure. You always "assume".

No, but for the 3pass case I need to overtake copper because
OS doesn't provide functions to get into ghost-mode.

|>
|> >If you can tell me how to CWAIT for x>222 if RKM says "this is illegal",
|> >well, then I could switch to use static ucopls switched with loadview().
|>
|> "The legal range of values is from 0 to 226".

"BUGS: User waiting for horizontal values of greater than 222 decimal
 is illegal"

:)

Anyone got different numbers ? ;)
I quote the v36 autodocs "third edition".
has it increased to 226 in OS3.0 ? WOW! :D

You can imagine that x=226 wouldn't help much more ;)

|>
|> --
|>                                 Michael van Elst
|>
|> Internet: [e-mail]
|>                                 "A potential Snark may lurk in every tree."
------------------------------------------------------------------------
   [e-mail] (Juergen "Rally" Fischer)   =:)