newb questions, hit the hardware or not?

[LiveForIt]

@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.

Many people have USB upgrades to there classic Amiga (Algor/Subway), and NG users don't have 9 pin bus mouse at all.

Other things people do that is annoying is that they assume they know BytesPerRow, this forces the game or program to only run in one screen resolution, and fixed mode ID's that can't be changed.

For examples if you write game/program to use Paula sound chips, then it might be faster on a MC68020, where don't have lot of CPU power, but you will not allow your game/program to use a modern sound cards like Prelude 1200 or any other sound card.

Sticking to graphic.library will make your game or program run on any hardware but, it will most likely run slower then if you wrote directly to memory, instead of using graphic draw functions, and so on.

[LiveForIt]

graphics.library goes directly to the hardware on native amigas.

I guess it depends on what you want to do, but writing directly too hardware might be slower.

Chipmem is slow, and fastmem is fast, so pre rendering into fast makes sense, if your doing a lot of read and writs from/to memory, and then using the most efficient way to transfare to chip memory.

The same is also true for modern graphic cards, writing directly to graphic card memory over the PCIe interface is slow, because it does not allow you to use DMA to copy the data.

The OS pen system is not most optimized for any picture format.

Again, before making such claims, please measure.

I should maybe not be so absolute in my statement.

it goes to the hardware of the graphics card if it supports 2D acceleration, same story. Only difference: It works on all hardware.

I take your word for it.

[LiveForIt]

On 20s and 30s there's no need for that, Especially the mouse and keyboard are very easy to handle properly with the OS.

its even easier to check the BITS, that's way some developers do it.
No need to reply intuition messages and so on, its maybe more common in games and demos.

and if some user can't use this, then I wonder how their Amiga is set up.

Some people like to use ModePro or some tool like that :-)
lol

Only using the OS in general is unacceptable for me, because it only helps NG users.

Not really, many Amiga1200/4000 users have Opalvision/Cybervison64/Cybervison3D/BlizzardVision, Grex/Mediator bus board upgrades some Roaden graphic card, sure they get around it by simply selecting a different video source on the monitor or some thing like that, or have two monitors connected, Its maybe more of convenience for this people, but might be problem for some with out scan double if they exist.

:-)

[LiveForIt]

@biggun

I'm shore it will help. But its just in drop in the sea.

The SAM 440 and 460 have a small Lattice fpga. The mentality of some of the so called next generation Amiga guys is to get away from hardware dependency.

It might not be connected in away that allowed it to be used emulate CIAA/CIAB.

I believe its used to control the clock speed, the FPGA is also programmed as GPIO, so it can be used in theory as joystick port easily. Just configure the pins as inputs, and make small 9pin dsub cable.

But to get it on right address I think you need to do some MMU magic.

They also may be trying to keep their AmigaOS closed for proprietary and security reasons.

Most things are no harder to do then on AmigaOS3.x, AmigaOS4.x is hackable if you like to, but its not open as you say.

[LiveForIt]

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

Where few remember the Hex values, do you have exceptional memory, or did you spent a lot of time looking at HEX code.

But I was told that some people find coding in C easier.

Its easier to debug some thing if you have some debug symbols, or else you need to remember the assembler code, some people have problems with that if they have not looked at code in a while, there for debug symbols and stack traces are big help. Even more so if your trying to fix something someone else wrote.

So if you are like me then coding everything right away in ASM is fine.

I think that comes with experience, if he knows what he want to do, and know how need to do it then that's fine.

But some times you don't know what best approach is and you need to try different methods out, to find the best one, unless you already know what best machine code to use, it maybe not best idea to spend too much time optimizing a bad idea, that your going trow away latter for a different approach.

I have seen few examples people spending a lot of time writing assembler code, to do some thing ending up doing every thing on the CPU, instead of using existing routines or OS functions that take advantage of DMA, and hardware acceleration.

Its also silly to not use a existing routine that someone has spent years perfecting, and ending up writing your own routines that ends up being slower. So its a good idea to do some bench-marking.

And if you did write better routine way not replace / optimize the old routine instead of bloating the code with duplication.

And when it comes to bug free code, I have see my share of programs that where so called bug free, that wrote out side of allocated memory blocks.

It a good idea to run Enforcer/Mungwall, program can run with out crashing, but yet corrupt memory for other applications or the OS, if blocks close to the block that was overwritten was reserved by another program this might happen while your writing the program so you might not notice it.

For example allocating some memory example 256, and counting to 256, instead of 255, that's a mistake that is so easy to do.

[LiveForIt]

Either the person at commodore/amiga who wrote trackdisk didn't understand the hardware, or it was written before functionality was added/worked and the code wasn't revisited.

The issue is that Amiga500 does not have lot RAM, there is space for pre fetching blocks.
Instead the disk has rotate to correct sector read a block discard the rest, rotate to next sector read a block and discard the rest.

The same problem you have now with faster ide/sata devices, now because the disk is so fast anyway so they don't care, but it is a problem for DVD and CD, if the filesystem is not smart about how to read blocks the it filters down to device io, where there is no intelligence to make it as efficient as possible.

Anyway perfecting every block in track on Amiga500 was not some thing they did, most likely because it takes up memory. When you have only 512k, then every byte count.

What does not make sense is way they don't do it today.

[LiveForIt]

If you read the abacus chapter you'll see that the trackdisk in 1.2 doesn't use the word sync to find where the track starts, it reads more than a track worth and then uses the cpu to search through the result. I think they might have stopped doing that in release 2.

Well it has to read the RAW data, decode the MFM, after the MFM is decoded can know whats on it, to see what block that was requested.

The disk format wasn't optimal for the hardware either. For reading it would make more sense if there was just one $4489 per track

Sure more data if there are no gaps, but I think comes down to filesystem, you don't want a too big blocks because, then small files take larger space, but physical storage and filesystem blocks does not need to be the same I agree. On the other hand with no sectors, the be only one CRC for large block of 4489, so more data being lost if there was a read/write error, maybe diving it into sector made it more reliable I don't know.

It looks like they wanted to allow sector writing because Paula can search for the sync word when writing

Some floppy drives / disks did have a sync hole, maybe it was legacy.

[LiveForIt]

Anyone who says that managing big assembly language projects is impossible, is basically saying that we humans are too damned stupid for that. Speak for yourself, please.

Humans are good at poison the food they eat sure they are stupid, from time to time they do some thing smart, but that's not often.

Regards
The Gray Alien from planet X.
(I run to hide in my UFO.)

[LiveForIt]

I would prefer that you asked for memory that was applicable rather than adding lots of layers which will just slow everything down when you pass the wrong type of ram.

It more efficient to reuse memory then to allocate memory. So if you have API allocates the memory for you, then you can not reuse the memory, then you will need to free it and reallocate memory using the API.