[Video] DFB1r4 pre-Christmas update

[Badwolf]

Morning all,

Bit of a hurried stream-of-conciousness video taking you through the progress to date on DFB1r4.




It's feeling much closer now!

BW

[mrbombermillzy]

Great progress there.

One question I will ask though. How much hassle would it be to get 512Mb+ on there?

[Steve]

Great progress there.

One question I will ask though. How much hassle would it be to get 512Mb+ on there?

I think sometimes it's too easy to think 'put lots of RAM on' but in all honesty, an Atari doesn't need much. For example, even though I technically can put 512mb in my TT with the Storm RAM expansion, I'm happy with 64mb - I run a fully loaded version of FreeMint with all Unixy stuff, modules loaded etc, and it barely uses 20% of the available RAM. Same thing on my Falcon which can technically have up to 512mb, I'm running one 128mb stick.

I'd say an accelerator only really needs 64mb and doesn't need any more than 128mb. Especially if it adds cost and complexity. Just my thoughts on the subject

[stephen_usher]

Indeed. People forget that software for these machines was written with what was then normal amounts of RAM. 64MB in 1991 was an unimaginable amount, except to high-end UNIX workstations costing >£20K. A Sun SPARCstation 2 by default topped out at 32MB, though there were ways to add more.

Just because today's bloatware can't even type "Hello World!" in less than 50MB doesn't mean that we should scale the old kit similarly.

[mrbombermillzy]

Not again!

Guys, think of the bigger picture.

If RAM was lower priced back then, this wouldn't even be an issue. We would all be maxing out to the 1/2/4Gb.

How far do we go with this argument? Nope, can't use an 060 in your system, as it was overkill in 1993/ no that HDD speed is not representative of 1994, so I'm slowing it down, or whatever.

There must be a retro machine you know that has benefitted from an extra RAM upgrade? Surely?

Yes, this amount of RAM (16/32/64) is fine if we just want to tinker with MINT or run Gembench and see how fast we can run Frontier, but wouldn't someone like to push the limits here, or give the option for someone to?

Like I said elsewhere, if its' a trivial thing to do, this would mean the difference of not having to either make some convoluted data compression/custom data loader and having game assets and data intact, rather than having to downscale, when not particularly necessary other than a (possibly trivial to implement) RAM limit.

And @stephen_usher it's not a matter of bloated code. I am currently working on a data saving set of routines for the Atari which will help with data efficiency and basically avoiding slow system bus access where possible, so I'm pretty anti-bloatware. The problem being high data content is high data content (no including swathes of redundant library functions here) even using assembly code.

Well anyway, that's my case put forward; it basically boils down to I have to do feature reduction for certain systems and not for others.

BUT...@Badwolf if it's anything but a minor modification and will cause a headache, I completely understand...hence the original question. However, someone else piping in and just saying 'no' because you don't have anything that needs it YET doesn't help

P.S. I love you guys! If the above sounds heated or angry, then I don't mean it to be; it's just me saying 'what a shame' (using many words) if it's a trivial thing to do!

[stephen_usher]

Bah! Modern systems have abstraction layers and frameworks to the ceiling just to print something, that's the bloatware, not necessarily user's code.

Anyway, this is off topic.

[Steve]

FYI @mrbombermillzy when I originally got my Storm RAM expansion for my TT, Ingo told me that it's best not to max out the RAM because he said it was quite taxing on the MMU/BUS. So there may be some considerations there. But I *do* know what you mean, although I don't honestly know how anyone could effectively utilise massive amounts of RAM on an Atari, even with multimedia. Most demos that take advantage of hard disks usually stream music data using DMA, rather than just loading it all into memory, so I don't think that kind of practice would ever change.

[sporniket]

although I don't honestly know how anyone could effectively utilise massive amounts of RAM on an Atari, even with multimedia.

To me, it seems @mrbombermillzy did mention that he do have a use case for that. And I agree with him provided it is trivial to do (not again all the kind of trouble you had @Badwolf to be able to write to the DSP, for instance)

If I recall correctly, a great entrepreneur/system designer that was firmly believing that 640Kbytes was more than enough was proven utterly wrong. (wink wink wink )

edit : more seriously, just provide the most storage area of any kind you can do, there will be people that will find a way to fill it to the brim.

[mrbombermillzy]

although I don't honestly know how anyone could effectively utilise massive amounts of RAM on an Atari, even with multimedia.

They don't ATM. That's the thing. And that's quite ok, if you are just running all the old skool Atari apps of yonder.

However, If you go on over to Amigaland and look at what people who have been given this RAM advantage are doing (i.e. Vampires); There's graphics/3D packages fully able to hold all the (24bpp) data without paging to (greater or lesser extent) slower HDD devices, making workflow easier. That's without any acceleration benefits included. This is older apps, but there are newer ones in the pipeline with this higher RAM spec, as Vampire is becoming a (still small but growing) standard there.

Anyway, I'm more than happy to discuss the benefits of more RAM in a system...Just PM me, so I don't have to argue a case over this thread any more.

@sporniket Thankyou! I'm not sure why I'm having to prove the case really.

[Steve]

Sorry @mrbombermillzy honestly I didn't mean to sound argumentative, was just playing devil's advocate