Welcome, Guest. Please login or register.

Author Topic: Time to say goodbye.  (Read 19592 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline whoosh777

  • Full Member
  • ***
  • Join Date: Jun 2003
  • Posts: 114
    • Show all replies
    • http://www.whoosh777.pwp.blueyonder.co.uk
Re: Time to say goodbye.
« on: August 14, 2003, 09:11:47 PM »

FWIW these are my plans and thoughts:

I gave up waiting for OS4 on 31st Jan 2003, that
was my deadline for them.

So my plan now is to buy a Pegasos II as soon
as these come out,

its £299 in the UK which I think is a bargain,
and for £200 I can upgrade it to a G4,


my A500 cost £395, my A1200 cost £395 also,

The difference being that I would have to buy
the RAM + graphics card in addition,

What I know is that Pegasos will deliver this
machine,

Now if Hyperion release A1-OS4 before Pegasos II
comes out then I may consider it,

If as I expect Pegasos II will come out first,
I will buy it, then if eg in 2005 Hyperion
release OS4 on A1 and this looks very interesting
then I will buy an A1 as well,

ie I would then have 2 machines Pegasos II and A1.

:this could have advantages regarding programming,
ie I could develop programs to run on both,

Now to play it safe I will try to only code on
Pegasos II using the OS3.0 API. Any Morphos specific
OS calls I will only use indirectly in such a way
that I could retarget them to OS4.

Thus my programs would be written in a way that
anticipates porting to OS4.

Other thoughts: IMO none of the current offerings is
a real Amiga, they are all 1/2 way to being real
Amigas.

What makes an Amiga an Amiga??

3 things IMO:

1. The OS. the current offerings: Morphos, AROS,
   OS4, Amithlon, emulators all satisfy this condition.

2. The custom h/w: none of the current offerings
   manage this. Only 2 things manage this:
   PPC OS4 and Coldfire (I think its called coldfire??)
   But these 2 options dont count as they require
   a legacy Amiga.

3. Tight integration of OS and h/w, again
   nothing provides this (other than PPC OS4 and Coldfire)

At the heart of a real Amiga is the copper chip:

no-copper-chip? no-Amiga!

Its the copper chip that gave us the perfectly smooth graphics  
and pull down screens etc,

Now if Eyetech comission and integrate the AGA chipset into
the A1, this would be a true Amiga.

I still havent understood why this cannot be done, surely they
could even use the legacy chips: the CPU communicates to the
chips via address-retargetting so this should be feasible via a
G3 for A1 and Pegasos.

Likewise if Pegasos re-implement from the RKM h/w manual
specifications the custom h/w that would become a true Amiga.

Really a true Amiga needs the custom h/w to be continued,
ie extend it with true colour, and "true" sound,
or at the very least simply remanufacture the custom chips
from the blueprints for legacy compatibility.

ie hack in some extra registers for truecolour support,
and maybe some for 16 bit per channel sound (or however many
bits is the current fashion). 16 bit version of classic sound
chips would be really interesting as the classic sound chips are
so straightforward to program

This way all classic programs including games would run
just as they did on your A500 or A1200,



whoosh777


This is what I am talking about which makes an
Amiga a true Amiga, the Amigas custom chipset:


struct Custom {
    UWORD   bltddat;
    UWORD   dmaconr;
    UWORD   vposr;
    UWORD   vhposr;
    UWORD   dskdatr;
    UWORD   joy0dat;
    UWORD   joy1dat;
    UWORD   clxdat;
    UWORD   adkconr;
    UWORD   pot0dat;
    UWORD   pot1dat;
    UWORD   potinp;
    UWORD   serdatr;
    UWORD   dskbytr;
    UWORD   intenar;
    UWORD   intreqr;
    APTR    dskpt;
    UWORD   dsklen;
    UWORD   dskdat;
    UWORD   refptr;
    UWORD   vposw;
    UWORD   vhposw;
    UWORD   copcon;
    UWORD   serdat;
    UWORD   serper;
    UWORD   potgo;
    UWORD   joytest;
    UWORD   strequ;
    UWORD   strvbl;
    UWORD   strhor;
    UWORD   strlong;
    UWORD   bltcon0;
    UWORD   bltcon1;
    UWORD   bltafwm;
    UWORD   bltalwm;
    APTR    bltcpt;
    APTR    bltbpt;
    APTR    bltapt;
    APTR    bltdpt;
    UWORD   bltsize;
    UBYTE   pad2d;
    UBYTE   bltcon0l;
    UWORD   bltsizv;
    UWORD   bltsizh;
    UWORD   bltcmod;
    UWORD   bltbmod;
    UWORD   bltamod;
    UWORD   bltdmod;
    UWORD   pad34[4];
    UWORD   bltcdat;
    UWORD   bltbdat;
    UWORD   bltadat;
    UWORD   pad3b[3];
    UWORD   deniseid;
    UWORD   dsksync;
    ULONG   cop1lc;
    ULONG   cop2lc;
    UWORD   copjmp1;
    UWORD   copjmp2;
    UWORD   copins;
    UWORD   diwstrt;
    UWORD   diwstop;
    UWORD   ddfstrt;
    UWORD   ddfstop;
    UWORD   dmacon;
    UWORD   clxcon;
    UWORD   intena;
    UWORD   intreq;
    UWORD   adkcon;
    struct  AudChannel {
      UWORD *ac_ptr;
      UWORD ac_len;
      UWORD ac_per;
      UWORD ac_vol;
      UWORD ac_dat;
      UWORD ac_pad[2];
    } aud[4];
    APTR    bplpt[8];
    UWORD   bplcon0;
    UWORD   bplcon1;
    UWORD   bplcon2;
    UWORD   bplcon3;
    UWORD   bpl1mod;
    UWORD   bpl2mod;
    UWORD   bplcon4;
    UWORD   clxcon2;
    UWORD   bpldat[8];
    APTR    sprpt[8];
    struct  SpriteDef {
      UWORD pos;
      UWORD ctl;
      UWORD dataa;
      UWORD datab;
    } spr[8];
    UWORD   color[32];
    UWORD htotal;
    UWORD hsstop;
    UWORD hbstrt;
    UWORD hbstop;
    UWORD vtotal;
    UWORD vsstop;
    UWORD vbstrt;
    UWORD vbstop;
    UWORD sprhstrt;
    UWORD sprhstop;
    UWORD bplhstrt;
    UWORD bplhstop;
    UWORD hhposw;
    UWORD hhposr;
    UWORD beamcon0;
    UWORD hsstrt;
    UWORD vsstrt;
    UWORD hcenter;
    UWORD diwhigh;
    UWORD padf3[11];
    UWORD fmode;
};

:they have to at least remanufacture this and possibly
extend it with some new registers

 

Offline whoosh777

  • Full Member
  • ***
  • Join Date: Jun 2003
  • Posts: 114
    • Show all replies
    • http://www.whoosh777.pwp.blueyonder.co.uk
Re: Time to say goodbye.
« Reply #1 on: August 15, 2003, 07:59:20 PM »

Quote:



whoosh777 wrote:

FWIW these are my plans and thoughts:


This is what I am talking about which makes an
Amiga a true Amiga, the Amigas custom chipset:


struct Custom {
UWORD bltddat;
UWORD dmaconr;
..........
UWORD padf3[11];
UWORD fmode;
};

:they have to at least remanufacture this and possibly
extend it with some new registers




Atheist wrote:

I have no clue what you just said, but HEY, you're speaking MY language.
I TOTALLY agree!!

===========================

Its the C way of hitting the classic h/w directly, ie that list
represents the custom chipset from a programmer POV.

For example you see dmaconr above, that == DMA-control-READ register
ie the last letter r == read

So in a C program if you want to read that register this is how you
would do it:

struct Custom *custom ;
UWORD dmaconr ;

custom = (struct Custom *)0xdff000 ;

dmaconr = custom->dmaconr ;

Thats it! dmaconr now contains the contents of the hardware register,

Likewise to control the soundchips directly (not through the OS)
you would type eg:

#include
#include

int main( int argc , char **argv )
{
BYTE *data ;
struct Custom *custom ;

custom = (struct Custom *)0xdff000 ;

data = AllocMem( 4 , MEMF_CHIP ) ;
data[ 0 ] = 0 ; data[ 1 ] = 50 ; data[ 2 ] = 0 ; data[ 3 ] = -50 ;
/* :define sound wave 0 50 0 -50   in chip memory */

custom->dmaconw = DMAF_AUD2 ; /* switch off any previous sound */
custom->aud[ 2 ].ac_ptr =(UWORD *)data ;/* tell channel 2 where the sound wave is */
custom->aud[ 2 ].ac_len = 2 ; /* word length of sound data */
custom->aud[ 2 ].ac_per = 450 ; /* how fast to play the wave */
custom->aud[ 2 ].ac_vol = 48 ; /* volume */
custom->dmaconw = DMAF_SET + DMAF_AUD2 + DMAF_MASTER ; /* begin playing the sound */

Delay( 500 ); /* play the sound for 10 seconds */
custom->dmaconw = DMAF_AUD2 ; /* switch off the sound */
FreeMem( data , 4 ) ;

return( 0 ) ;
}

this program would play the sound wave for 10 seconds.
(I havent tested this out, but wrote it on-line by looking at the
h/w RKM pages, some of the numbers eg 450 may need to be changed
to make the sound audible )

People who hit the hardware directly usually do it with assembler,
however its much simpler (but slower) via c, once the sound starts playing
it will be *identical* to if it had been done via assembler.

Anyway the point I am making is that the custom h/w pretends to be
memory locations, in fact what happens is that
the address bus is intercepted and the data bus is then redirected to
the actual custom h/w. Thus it ought to be possible to
use the same interception trick on eg a G3.

The problem with emulating h/w with s/w is that you lose the
perfect timing, one of the reasons classic games had such smooth
graphics was that the entire h/w is perfectly synchronized with the
video beam, with the copper chip arbitrating memory accesses
within each scanline,
Total synchronisation, no way can s/w emulation of the custom chips
achieve such dexterity.

There is some inertia to change screen palettes which amounts to
either 1 or 2 video lines,
so when you slide down a classic screen there are either 1 or 2 lines
of space between any 2 consecutive screens.

People with emulators think they know what an Amiga is,
unfortunately for them the classic Amiga is still ahead in terms of
h/w time synchronisation so its a bit like me viewing a truecolour
screenshot via HAM8.

BTW I am not a h/w person, so some of the above may have
been naively presented,


>AmigaOne! Bring on the (near) perfect address space emulation for the
>old custom HW in AOS4.0!!!!!!!! (or a PCI card)

as long as its h/w emulation, s/w emulation of h/w sucks,
(s/w emulation of h/w requires MMU and page faults, page fault mechanism
is going to ruin any hopes of the perfect almost hypnotic
time synchronisation of classic Amiga h/w

>Amiga RULEZ!!!!

In terms of timing, yes it still does!

whoosh777
 

Offline whoosh777

  • Full Member
  • ***
  • Join Date: Jun 2003
  • Posts: 114
    • Show all replies
    • http://www.whoosh777.pwp.blueyonder.co.uk
Re: Time to say goodbye.
« Reply #2 on: August 16, 2003, 01:32:39 AM »

In case its of interest here is a debugged + improved
version of the above soundwave program:

http://www.whoosh777.pwp.blueyonder.co.uk/tone.c

it plays a smoother sound wave for 2 seconds,
a pleasant tone sound,

here is the binary:

http://www.whoosh777.pwp.blueyonder.co.uk/tone

just 2k, if you have a classic Amiga
then run it

tone

and tone will occur for 2 seconds through channel 0, you can try other
periods + volumes thus:

tone period volume

period + volume are complicated to understand,
but 64 is maximum volume == 0 decibels,

period relates to the frequency, 130 is the
current default value

Anyway OS-emulation is not enough to run such a program,
you would need at least s/w emulation of the custom chips,

I am not sure how s/w emulation would cope with a more complex
version of this prog that had one channel modulating frequency + amplitude
of another.

According to the RKM each audio channel is allocated one DMA slot
per horizontal scan line of the video beam, this is going to
be tricky to emulate accurately in s/w, note that many classic games use tricky
timing eg with floppy drives as a piracy prevention measure.

You could emulate the custom h/w to some extent but I think it
will always lack the precise timing and synchronisation of a true
Amiga.

for these reasons I believe someone must incorporate the custom h/w
or a clone thereof in future Amigas then OS3.9 could be done merely
by using a 68030 emulator, ie emulation of CPU only.

But because Eyetech refuse point blank to bring the custom chips
(probably because Gateway have raided the IP), Hyperion have
got their work cut out. Were Eyetech to do the custom chips the
A1 + OS3.9 could easily be out in maybe 3 months it would really
turn the A1 project into a non-issue, however without the custom chips and
its a major issue.