Chunky pixels sans akiko?
William Silvey
Does anyone out there know if it's possible to emulate the chunky pixel effect
without Akiko onboard? [I'm considering working on a wolf3d clone for the
1200]
[Woke up this morning, put the Akira soundtrack on, found out]
[my board had picked up rec.arts.anime. It's gonna be a good]
[day! WRITE ME! wsi...@online.oau.org ]
[ ]
[ Amiga to the Bitter End ]
Maarten Ter Mors
All...
WS> Being somewhat new to the field of amiga programming, I have to ask:
WS> Does anyone out there know if it's possible to emulate the chunky pixel
WS> effect without Akiko onboard? [I'm considering working on a wolf3d
WS> clone for the 1200]
KickStart 3.1 (V40) is said to have (a) ROM function call(s) to handle the
chunky<>planar conversion. The good thing about this is, that it is combined
with another feature of 3.1, i.e. auto-sensing what the system-configuration
is.
Simply said, this means that the ROM will emulate the Akiko chunky<>planar part
(it does more than just that, but it's its most famous feature) by means of the
processor. This is also why the CD남-upgrade board for the A4000 series (yet to
be released by C=) will not even have one on-board, since the 68030 and '040
series of processors are more than capable of handling the conversion by
themselves and doing all the '020 in the CD남 does in the same timespan.
The obvious downside to this software-emulating approach is, of course, the
speed. Especially on a vanilla A1200, the speed will not be great, not to say
unbearably low. So you'd be writing your Wolfenstein clone for rather high-spec
machines, with at least a 68030 and Kickstart 3.1 :-((
So long mateys,
/|/| ___ /|/|
/ / |aarten |er / / |ors
Ben Vost
: Being somewhat new to the field of amiga programming, I have to ask:
Well, you could always write it for those of us Amiga users that actually have
a chunky pixel capability. You all know who I am talking about... Picasso,
Retina, Spectrum owners! That would be great! 256 colours, texture mapping, yum!
Hell, why bother to do a wolf clone, get stuck in at the top and do a DOOM clone
instead!:)
Happy Noo Year!
Ben
--
,--------------------------------------------------------------------------.
|"Why? Because I can..." | Amiga 3000T, 14MB RAM, Picasso II, VLab, CDTV, |
| | .5GB Hard Drive Space, 250MB Tape Streamer, NEC|
| Ben Vost | 4FG, Supra 14.4k, JX100, loadsa software... |
|--------------------------------------------------------------------------|
|Email B...@subway.demon.co.uk Tel/Fax/Data: (+44) 081 567 4623|
|SMail Ben Vost, BVCC, suite 10, 46 Windsor Road, Ealing, London, UK W5 5PE|
`--------------------------------------------------------------------------'
Peter McGavin
Maarten....@p6.f120.n100.z60.wlink.nl (Maarten Ter Mors) wrote:
>KickStart 3.1 (V40) is said to have (a) ROM function call(s) to handle
>the chunky<>planar conversion.
I'm not sure if Maarten means the graphics.library WritePixelArray8(),
ReadPixelArray8() and related functions, but they handle
chunky<>planar conversion and have been available since KickStart 2.0
(V36).
--
Peter McGavin. (pet...@maths.grace.cri.nz)
William Silvey
rather not waste my time writing game for an installed userbase of six people
in N.America.
Maarten Ter Mors
All...
PM> KickStart 3.1 (V40) is said to have (a) ROM function call(s) to handle
PM> the chunky<>planar conversion.
PM> I'm not sure if Maarten means the graphics.library WritePixelArray8(),
PM> ReadPixelArray8() and related functions, but they handle chunky<>planar
PM> conversion and have been available since KickStart 2.0 (V36).
Er....well, I don't know what I mean, actually :)) I just heard from a
developer that the Akiko functions could be emulated by software when needed, in
V40 that is. It seems like a logical thing to do, since the CD32-upgrade for
the 4000 will not have this chip.
However, I can't test this, as I 'only' have 3.0 :-))
G'bye everyone,
/|/| ___ /|/|
/ / |aarten |er / / |ors email: maarten....@aobh.wlink.nl
John Bolton
Maarten Ter Mors <Maarten....@p6.f120.n100.z60.wlink.nl> wrote:
:Well, now ! It seems someone by the name of Peter McGavin wrote a message to
:All...
:
:
: PM> KickStart 3.1 (V40) is said to have (a) ROM function call(s) to handle
: PM> the chunky<>planar conversion.
:
: PM> I'm not sure if Maarten means the graphics.library WritePixelArray8(),
: PM> ReadPixelArray8() and related functions, but they handle chunky<>planar
: PM> conversion and have been available since KickStart 2.0 (V36).
:
:Er....well, I don't know what I mean, actually :)) I just heard from a
:developer that the Akiko functions could be emulated by software when needed, in
:V40 that is. It seems like a logical thing to do, since the CD32-upgrade for
:the 4000 will not have this chip.
:However, I can't test this, as I 'only' have 3.0 :-))
KS 3.1 (V40) detects whether or not your Amiga has the Akiko chip. If
not then the function is performed in software. Earlier versions
(V36 - V39) do not check for Akiko and therefore ALWAYS do it in
software.
Juergen Fischer
Could it be possible to rebuild Akiko with TTL's and put
it at that adress the CD32 Akiko uses (If I'm right it's only
one adress, you write 8 bytes and then read the 8 converted bytes
from that adress)?
Juergen
Kasimir Blomstedt
>Juergen
* DREAM MODE ON ??*
I think the best way to implement chunky pixels would be to have
two address decoders into the same memory-area, which would thus be
mapped into two separate address spaces. When writing to one address
space everything would work normally, i.e a byte written would end
up in one mem-chip, but writing to the other address space a byte
would be split into 8 mem-chips (one bit into every chip.. this would
require some buffering registers before the chips, so other bits in the
chip wouldn't be corrupt). This way one would have the benefits
of both chunky and planar architectures.
To get the most out of this arrangement, the "special" memory area
should be automatically copied into CHIP mem (not using the processor).
This copying would take up almost all CHIP mem cycles left for the processor,
so some ordinary FAST memory should be added to this design also.
To speed up special effects, e.g Gouraud shading, this "special" 8-bit (8
mem chips) memory could be accessed with long words, so that only the UPPER
8-bits of the long-word would be written -> the lower 24-bits can be used
as the decimal part of a 8.24 fixed point number.
The only difficulty I've come up with this design is that external
cards don't have separate address/data buses to CHIP mem and to the
processor.. -> the idea of automatically copying the "special" memory
into CHIP mem while the processor is free doing other things in FAST
memory doesn't work.. (I don't even know if an external card can access
CHIP mem at all..)
* DREAM MODE OFF *
- Kasimir Blomstedt, kblo...@vipunen.hut.fi
Juergen Fischer
admit being in "dream mode". But I think rebuilding Akiko isn't
that difficult (And with using it, chunky operations seem to bee
quite fast). Should be no problem for a freak (how to add
it? Does the A1200 have an expansion slot ?).
Isn't there anybody out there saying 'yeah i gonna do it' ?
Juergen
Teemu Suikki
Yes. And the akiko address isn't fixed, it is in gfxbase.. That is, programs
must read the address from there.
So one could build a chunky-to-planar converter, then just set the right
address to gfxbase..
--
PROC main();DEF a,b,c;b:='** email: tsu...@lut.fi **';Vprintf(a:='P'+
'ROC main();DEF a,b,c;b:=%lc%s%lc;Vprintf(a:=%lcP%s%.69s%s%s%lc,%lc[c:'+
'=39,b,c,c,b:=[$%8lx,0],a+1,b,a+70,c,10,^b,10]);ENDPROC/*E .sig!*/%1lc',
[c:=39,b,c,c,b:=[$272B0A27,0],a+1,b,a+70,c,10,^b,10]);ENDPROC/*E .sig!*/
Florian Sauer
Of course! Even the address of the register has not to be nessesary to be
the same as in the CD32, since the location has to be stored in the graphicsbase.
In fact even the those people who are "hitting the hardware directly" :) get
the address from there... hahaha
Florian
Bernd Raschke
... and are dog slow. But since V40 there's WriteChunkyPixels() and it's
a) faster
b) uses the chunky-conversion-chip in Aikiko if it's there.
Ciao,
Arty
---
Snail: Bernd Raschke, Hartmannstraße 129/Zi.426, D-91058 Erlangen
Voice: +49 - 9131 - 32456 | Irc: Arthur _ | Save C= Amiga -
Internet: bdra...@cip.informatik.uni-erlangen.de _ // | buy a CD³²!
UUCP: arthur@thera.(adsp|nbg).sub.org \X/ |