newb questions, hit the hardware or not?

[biggun]

I would also discourage to directly hit the hardware. There are a couple of new cores for FPGA in development (FPGA Arcade and the Apollo core are examples, but I also know of at least two others). If you want that your software runs everywhere it is a safer bet to use the OS.

I can only speak for Apollo/ Phoenix CPU and for the S-AGA Chipset.
With them you can savely hit the hardware as you are used to do it.
I myself write old school copperlists when I write demos testing the CPU or the AGA chipset.
So doing this is save and no problem at least for the Apollo/Phoenix CPU and the SAGA++ chipset.

[biggun]

@Thorham

Hit the hardware is issue of speed vs comparability / flexibility, for the user it means it will limit there hardware choice..

It depends on what you want to do, for most part you should avoid banging the hardware, but if you are interested in making a OCS game for Amiga500, it makes the most sense to take advantage of every CPU cycle you can get, and try to avoid the overhead of the software API.

Writing a game for a modern graphic card, and using CIAA/CIAB timers, will exclude many people from using your software (AmigaONE-*/Sam4*0), there for its not a good idea.

Poking around in $DFF00A and $DFF00C, to get Joystick and mouse, will limit your software to only to work with 9 pin joysticks, and mouse, and will not allow your software to support USB mouse and Joysticks.

What you say it correct.

But it does not need to be like this.
A CIA need minimal FPGA
By adding the smallest and cheapest FPGA to a new system - every system could be made CIA compatible for a price of close to nothing.

The same is true with USB and accessing them via DFFxxx registers.
A USB to DFFxxx bridge logic costs around $2.

Technically there is really no reason to not havce both.
A NEO sytem could with no problem at all implement USB and DFF chipset and CIAs for nearly not money.

[biggun]

Isn't this two tasks for two people?

1) The application developer should focus on solving his problems effectively.

2) The compiler writer should improve the compiler so that reasonable good code is generated.

To write an application like a texteditor, using C and using OS calls sounds perfectly ideal to me.

If you want to write a 1KB bootblock demo with sinus scroller and copper-plasma, then using ASM and banging the hardware is probably the ideal way of doing it.

[biggun]

you're talking nonsense.

"Bull.

"what an asshøle."

How about we try to stay calm and behave?
Maybe we could even go back to the main topic?


I think the main question was is going directly onto the hardware OK?
And I think we can agree that this is OK - as long as one is aware that running on OS4 machines is then not working.

One think is clear and everybody will agree to this.
Coding in high level languages is easier.
Coding complex routines in ASM takes more time.

[biggun]

Just because it's easier to make mistakes doesn't mean you can't properly debug your code. Writing good software in assembly language just takes longer. Also, the bug riddled thing makes it sound like you can't write good software in assembly language, which is obviously nonsense.

Yea - I know what you mean,
God blessed me with the gift that I can write the most complex algorithms and they are always bugfree.
I never need to debug. Whether I write in C or ASM or right away in hexcode. My code is always bug free.
;-)

So if you are like me then coding everything right away in ASM is fine.
But I was told that some people find coding in C easier.

[biggun]

You either have a different definition of complex than I do, or that is sarcasm, or both.

Haha lol.
I thought a little bit of fun does not hurt, right :-D
Better than people getting at each others throats here.


But its true that I write sometimes a handfull instructions in Hexcode directly.
As you know I did develop the instruction decoders for three full 68K CPUs (68050/Apollo/Phoenix)
therefore I have quite good practise in knowing how every 68K instruction is encoded....