04 June 2021, 04:04 | #1 |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,281
|
Ram vs Rom speed
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?
|
04 June 2021, 04:08 | #2 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,186
|
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.
|
04 June 2021, 04:09 | #3 |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,281
|
|
04 June 2021, 04:15 | #4 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,186
|
It is indeed a shame. There's a very good reason to bypass the OS: the chipset support is not good.
|
04 June 2021, 09:44 | #5 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,409
|
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.
|
04 June 2021, 10:55 | #6 |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,743
|
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... |
04 June 2021, 11:14 | #7 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,409
|
Quote:
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. |
|
04 June 2021, 12:07 | #8 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Quote:
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? |
|
04 June 2021, 12:20 | #9 |
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,544
|
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! |
04 June 2021, 12:33 | #10 | ||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Quote:
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. Quote:
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. |
||
04 June 2021, 13:00 | #11 | |||
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,186
|
Quote:
Quote:
Quote:
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. |
|||
04 June 2021, 13:13 | #12 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
Quote:
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. |
|
04 June 2021, 14:15 | #13 | |||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,409
|
Quote:
Quote:
Quote:
|
|||
04 June 2021, 15:28 | #14 |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,281
|
@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? |
04 June 2021, 15:31 | #15 |
Registered User
Join Date: Jun 2015
Location: Germany
Posts: 1,918
|
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.
|
04 June 2021, 15:40 | #16 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Quote:
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. It programs would have used audio.device, this redirection would be immediate. |
|
04 June 2021, 15:42 | #17 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Quote:
So yes, it certainly does proper abstraction, which does not exclude user errors. |
|
04 June 2021, 15:45 | #18 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Quote:
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. |
|
04 June 2021, 15:50 | #19 | |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,186
|
Quote:
|
|
04 June 2021, 15:55 | #20 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Quote:
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. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
16MB EDO RAM, 256KB/1MB SIMM RAM, Macintosh/Atari/Amiga ROM & other accessories | mdanh2002 | MarketPlace | 0 | 27 June 2019 16:41 |
3.1.4 speed difference MapROM vs ROM? | Firestone | support.Apps | 6 | 28 November 2018 20:42 |
Throttle RAM speed | vagrant | support.WinUAE | 13 | 03 August 2017 21:02 |
A600 multi-upgrade (Chip RAM + Fast RAM + ROM + IDE2CF) | Astrofra | Hardware pics | 15 | 18 February 2014 21:27 |
how is it possible for a RAM upgrade to speed up music? | lost_lemming | support.Hardware | 9 | 17 February 2010 22:08 |
|
|