Ram vs Rom speed

[sandruzzo]

According to HW manual, 68000 can access to rom at full speed without waiting for available dma' slots. Isn't worth using rom as much as possible(blitting, audio, etc...) to archive full 68000' speed on base Amiga configuration?

[Samurai_Crow]

It depends on how well written the ROM routines are. Graphics.library is mostly trash. Audio.device is also worthless. Intuition.library is only as good as its dependency on Graphics.library allows it to be.

[sandruzzo]

Originally Posted by Samurai_Crow

It depends on how well written the ROM routines are. Graphics.library is mostly trash. Audio.device is also worthless. Intuition.library is only as good as its dependency on Graphics.library allows it to be.

it's a shame!

[Samurai_Crow]

It is indeed a shame. There's a very good reason to bypass the OS: the chipset support is not good.

[roondar]

Hmm, I suppose it'd be possible to create a special "Game OS" ROM to achieve what sandruzzo is hoping for. But then, that'd be pretty useless for all but games and really only benefit machines without Fast RAM. And realistically, if someone would be willing to go to the trouble of replacing the ROM in their Amiga, they'd probably also wouldn't have problems installing some true Fast RAM instead - which overall probably would be more useful.

[pandy71]

Technically - RAM can be used in ROM address space (and this "shadow" RAM itself could be writable in different address space if FC0..FC2 used - FC is normally not used in Amiga so some effort is required on this also but nowadays this seem to be nothing unusual).
At least additional ROM space can be used for this...

[roondar]

Originally Posted by pandy71

Technically - RAM can be used in ROM address space (and this "shadow" RAM itself could be writable in different address space if FC0..FC2 used - FC is normally not used in Amiga so some effort is required on this also but nowadays this seem to be nothing unusual).
At least additional ROM space can be used for this...

Oh, absolutely!
But at that point, you may as well just use true Fast RAM for the functions and be done with it. In all honesty, I fully agree with sandruzzo's long held point that the Amiga would've been a better system if it had come with both Chip & Fast RAM out of the gate. This discussion about using ROM for chipset access routines seems to kind of play into that.

Anyway, the nerd in me would love the idea of an Amiga with software swappable ROM space and people using this to make the A500/A1200 into a console of sorts. Sounds like a fun idea to me. But then, I came from the C64 and always missed the cartridge slot on my A500

Edit: didn't Commodore try to make the OS GFX functions much better for 3.0? I seem to recall them actually pointing this speed difference out about the A1200 and saying something along the lines of "ROM isn't slowed down, so using ROM routines is going to be faster than writing your own code". In the end I don't think the speed advantage was actually there, but it shows they were talking about the same thing back in 1992.

[Thomas Richter]

Originally Posted by Samurai_Crow

It depends on how well written the ROM routines are. Graphics.library is mostly trash. Audio.device is also worthless. Intuition.library is only as good as its dependency on Graphics.library allows it to be.

Cough. Let's be serious. Yes, graphics is trash, but not on the actual blitter usage side. If you believe you can write a generic BlitRastPortBitMap() any better, let me know. Graphics services are complicated because they have to attempt a complicated task: Generic rendering into partially obscured bitmaps, plus "save-under" storage, plus maintenance of these structures.



The graphics problem is at software engineering, lack of a clear structure, and lack of abstraction. That wouldn't make it any faster, but much easier to extend towards RTG.



Audio.device is certainly useful, and saying it's worthless means that you haven't understood its values. You seem to prefer to "hack and slash" the hardware, but that's again non-trivial due to some idiocracies of Paula, and the audio.device having to work around them. Or are you telling me that the typical "busy-waiting for end of line" approach taking by many poor trackers are an exercise of good engineering?

[Bruce Abbott]

Originally Posted by sandruzzo

it's a shame!

You know what's really a shame? Nobody produced a cartridge slot for the Amiga.

It wouldn't have been hard. The A1000, A2000 and A500 all have a nice expansion bus connector. There's plenty of space in the memory map, and simple ways to make the machine boot from a cartridge. It would free up RAM for graphics and sound etc., make loading times much faster, and of course eliminate DMA contention. If some game needed a special function like C2P or MIDI sounds, the cart could have extra hardware put into it to do the job. The floppy drive could still be used for game saves etc. Finally, copy protection wouldn't be so onerous because ROMs don't get read errors so there's no need to make backups.

Just imagine how much more sophisticated and higher performance Amiga games could have been on cartridge. No need to expand your A500 because the latest games need more RAM, or a hard drive to avoid multi-disk loads. Porting from consoles would be easier with better results, and piracy would be eliminated so developers would be more inclined to produce Amiga titles.

"But they cost a lot more to make than a floppy disk", you say, "so people wouldn't have bought them!". Yet I remember some games on floppy disk costing over $100, and cartridge games would be worth paying extra for.

Today it is still relevant. Somebody should bring out a game cartridge with EEPROM on it that be loaded from your Amiga or a PC, then developers would make games for it. Perhaps even go nuts and put a Pi Zero in there that emulates ROMs and even a faster CPU, RTG graphics etc., all available just by plugging a slim module into the side of your stock A500. We could have what the Amiga should have had back in 1985!

[Thomas Richter]

Originally Posted by roondar

Anyway, the nerd in me would love the idea of an Amiga with software swappable ROM space and people using this to make the A500/A1200 into a console of sorts. Sounds like a fun idea to me. But then, I came from the C64 and always missed the cartridge slot on my A500

But the Amiga has this all along. The entire Kickstart is constructed in such a way that you can exchange the ROM components with RAM components. LoadModule does just that for you. The only downside is that the Os does (did) not load disk based modules for you automatically, and that changed in 3.2.

Originally Posted by roondar

Edit: didn't Commodore try to make the OS GFX functions much better for 3.0?

They did. There was a first major overhaul in 2.0 going on that improved the speed of many ROM based funtions like MrgCop(), SetRGBxx() or the region computation logic, partially by streamlining and replacing the C code with assembler code.


There was a second overhaul around V39/V40 to easy integration of RTG. It wasn't fully done, CBM was running out of money, but the graphics vecinfo abstraction for low-level functions was from that time.


So, I frankly don't believe that you can write the generic blitter and copper handling stuff much better yourself. The complexity comes from the complexity of the use case. Any blit needs to be potentially clipped at layer/cliprect boundaries, split into multiple parts over multiple rectangular image regions, support all shift values and all minterms. That's not the same thing as your average gaming "Oh, I don't care the shit if the bobs cross the boundary" engine.

[Samurai_Crow]

Originally Posted by Thomas Richter

Cough. Let's be serious. Yes, graphics is trash, but not on the actual blitter usage side. If you believe you can write a generic BlitRastPortBitMap() any better, let me know. Graphics services are complicated because they have to attempt a complicated task: Generic rendering into partially obscured bitmaps, plus "save-under" storage, plus maintenance of these structures.

Layer support is offloaded to Layers.library as it should be. That section of ROM is worthwhile. QBlit() is ok too except that it's treated as private. When doing deferred rendering QBlit() could have stood on its own. In the early Kickstarts, the way to work around the offset overwriting the word before the blit region was "solved" by activating an otherwise unneeded DMA and slowing down the whole blit. QBlit() has always had pre- and post-blitting callbacks that could have stored and retrieved that 16-bit section of memory with the CPU. If that made it to the 3.0 ROM it was far too late.

The graphics problem is at software engineering, lack of a clear structure, and lack of abstraction. That wouldn't make it any faster, but much easier to extend towards RTG.

Only if that's your goal. I was told at the 1998 DevCon that FX.library was planned to replace MrgCop() so that CMove would be encoded at compile time using C macros. That library's sources were lost to the sands of time by then. If the Copper's capabilities were abstracted to FX.library, RTG would have been possible in the 90's without making the Amiga chipset users suffer.

Audio.device is certainly useful, and saying it's worthless means that you haven't understood its values. You seem to prefer to "hack and slash" the hardware, but that's again non-trivial due to some idiocracies of Paula, and the audio.device having to work around them. Or are you telling me that the typical "busy-waiting for end of line" approach taking by many poor trackers are an exercise of good engineering?

Copper timing is more reliable than CPU timing because the caches on the CPU use busy looping pointless. Most music playback could have been reduced to a callback hook on a feeder to a Copper list.

Audio.device was too thin of an abstraction such that when AHI extended the Audio.device APIs, nothing suddenly was redirected to the sound cards anyway because almost nothing used it.

[meynaf]

Originally Posted by Thomas Richter

Audio.device is certainly useful, and saying it's worthless means that you haven't understood its values. You seem to prefer to "hack and slash" the hardware, but that's again non-trivial due to some idiocracies of Paula, and the audio.device having to work around them. Or are you telling me that the typical "busy-waiting for end of line" approach taking by many poor trackers are an exercise of good engineering?

Aside of channel allocation so direct hardware access under OS becomes possible, yes audio.device is worthless.
As it does not properly work around these idiocracies you mention -- as a result all trackers that used audio.device (f.e. maxtrax) failed on accelerated machines.
So the busy-waiting approach is perhaps not good engineering but at least it can work without missing notes.

[roondar]

Originally Posted by Thomas Richter

But the Amiga has this all along. The entire Kickstart is constructed in such a way that you can exchange the ROM components with RAM components. LoadModule does just that for you. The only downside is that the Os does (did) not load disk based modules for you automatically, and that changed in 3.2.

That's actually quite cool. So does this mean that someone could, in theory, design a side slot expansion for the Amiga 500 that's essentially like a console game cartridge and have it start automatically? I'm guessing the answer pretty much has to be yes, considering some expansions (ACA500/Action Replay/A570/etc) can 'take over' the system on boot.

They did. There was a first major overhaul in 2.0 going on that improved the speed of many ROM based funtions like MrgCop(), SetRGBxx() or the region computation logic, partially by streamlining and replacing the C code with assembler code.

There was a second overhaul around V39/V40 to easy integration of RTG. It wasn't fully done, CBM was running out of money, but the graphics vecinfo abstraction for low-level functions was from that time.

Cool, thanks for the info.

So, I frankly don't believe that you can write the generic blitter and copper handling stuff much better yourself. The complexity comes from the complexity of the use case. Any blit needs to be potentially clipped at layer/cliprect boundaries, split into multiple parts over multiple rectangular image regions, support all shift values and all minterms. That's not the same thing as your average gaming "Oh, I don't care the shit if the bobs cross the boundary" engine.

You may well be right, gaming Blitter engines tend to do as little as possible to be as fast as possible. They often don't even do any clipping to begin with and I've seen quite some code that only supports a single size of blits.

[sandruzzo]

@roondar

Nothing would have been better than even as little as 64k of fast-ram, to achieve a better performance for ocs, that's why I was wondering if some sort of speed-up could be achieved by using rom...

Could it fly on A1200?

[grond]

ROM code being faster than chipmem custom code is an argument in favour of using the OS that I read in some Amiga programming books.

[Thomas Richter]

Originally Posted by Samurai_Crow

Layer support is offloaded to Layers.library as it should be.

It would be nice if things would be that simple. While layers implements the typical layers re-organization, splitting up rendering operations into cliprects is up to graphics.

Originally Posted by Samurai_Crow

QBlit() is ok too except that it's treated as private.

QBlit() and QSBlit() are standard public grapics.library calls, they are also documented in the RKRM. They are pretty useful, but the overhead seem to be too large for your average blit, and busy-waiting on the blitter-done bit was just faster. IIRC, early kickstarts had a smarter rendering-dispatch mechanism (probably through QBlit()), but it was just slower than necessary.

Originally Posted by Samurai_Crow

Audio.device was too thin of an abstraction such that when AHI extended the Audio.device APIs, nothing suddenly was redirected to the sound cards anyway because almost nothing used it.

It programs would have used audio.device, this redirection would be immediate.

[Thomas Richter]

Originally Posted by meynaf

As it does not properly work around these idiocracies you mention -- as a result all trackers that used audio.device (f.e. maxtrax) failed on accelerated machines.

Hardly. Audio.device works just fine on my machine, which is fairly accelerated. DMusic2, for example, plays through the audio.device, and yes, it does work reliable on my accelerated Amiga.


So yes, it certainly does proper abstraction, which does not exclude user errors.

[Thomas Richter]

Originally Posted by roondar

That's actually quite cool. So does this mean that someone could, in theory, design a side slot expansion for the Amiga 500 that's essentially like a console game cartridge and have it start automatically?

Yes, of course. That is what the F-Space was designed to be good for. If anything is present there, and has the right "magic bytes", it's getting started very early in the kickstart. Also, if there are resident modules in the F-space, they are added to the kickstart and replace them.


Unfortunately, the F-Space was taken hostage by many accelerators for their own business, mostly to provide board-specific services. If I recall correctly, some specs even call it the "cartridge space".


But, as said, no longer usable today.

[Samurai_Crow]

Originally Posted by Thomas Richter

Hardly. Audio.device works just fine on my machine, which is fairly accelerated. DMusic2, for example, plays through the audio.device, and yes, it does work reliable on my accelerated Amiga.


So yes, it certainly does proper abstraction, which does not exclude user errors.

I tried doing a streaming app using Audio.device and it came out choppy, even with an 020. Audio.device is not all it's cracked up to be. I stand by my earlier statement that Paula registers can (and should) be written using the Copper for more precise timing than the CPU can do in a multitasking OS.

[Thomas Richter]

Originally Posted by Samurai_Crow

I tried doing a streaming app using Audio.device and it came out choppy, even with an 020. Audio.device is not all it's cracked up to be. I stand by my earlier statement that Paula registers can (and should) be written using the Copper for more precise timing than the CPU can do in a multitasking OS.

I'm not clear what you were doing, but you can pile up audio samples at the device and it would play them seamlessy, i.e. without "pops" when switching sample buffers. It's actually not that complicated, Paula creates an interrupt whenever it can take a new sample address, and the audio.device is just doing that in its own interrupt.