Relatively often we see a 65xx system with more than 64k of RAM - sometimes an '816 system, sometimes an '02 system with memory banking or paging.

But here's a discussion question: what to do with a large memory model? What's the killer app, or the driver, or the useful-thing-to-do, with lots of memory?

Interesting to hear both about actual things-that-have-been-done, and things-that-might-be-done.

For a hobbyist working alone on a program, 64K is normally an awful lot of memory to fill with program material on a 6502, in assembly language or in a memory-thrifty language like Forth. Certain compiled languages are big memory hogs and might need more. My own interest in more memory is for data and memory-resident files; for example:

• Well commented source code can take a lot of space, and running an assembler on it will probably work a lot better if you can keep the entire source code (which may reside in multiple files) in memory all at once.
• I've done digital audio recording, and that can run through tens of thousands of bytes per second.
• My pre-calculated large look-up tables for ultrafast math performance, if you download the entire set, take 2MB.
• Brad is talking about 4MB of video screen memory to use with his 6502.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

More than 64k is easily used for a graphics frame buffer. With black and white 640 x480 is still 38k, adding any colour will take the requirements over 64k. And that is without off-screen requirements like images or fonts.

Multitasking is another good reason to have lots of RAM, as soon as you want to have more than one application in memory at a time the requirements go up a lot.

For me, like Garth said, source code. Swapping to disk can be quite painful at times. It's actually the sole reason my assembler doesn't utilise include files, which is the one feature I miss.

Some 8-bit home computers of the 80s had 32K ROMs, containing BASIC (including FP math library), fonts, and a BIOS. That's half the address space right there.
A 160x200 4bpp frame buffer is 16K. A 320x200 bpp frame buffer would be 32K.
For sound, if you'd prefer wave samples over a discrete programmable sound generator, then those can take up lots of memory.

As a reference, the Williams Defender arcade machine from 1980 (1MHz 6809 CPU) had a 4bpp frame buffer spanning 40K of address space, which it drove entirely in software. The system made extensive use of ROM bank switching to access all its code and graphics. It also had wave-base sound, although that was on a separate sound processor board with its own CPU and ROM.

If I were back in the 80s and I had a wish-list for a 6502 computer where programs are developed in situ (as opposed to writing them on a separate machine as I would do now), then maybe my greatest ask would be for a system such that my assembled program would execute in a 2nd memory bank where it could not corrupt the operating system and source code buffers... i.e. so the cost of a bad program wasn't an N-minute reload. That's similar to the multitasking idea that another poster mentioned.

Disk buffer space.

Data arrays.

String space for BASIC.

Swap space in a multitasking O/S.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks for all the thoughts, everyone. I wonder if there's any benefit in trying to organise the different types of use into themes.

For my own part, I've recently been helping hoglet's building of Life programs for large-memory machines. Using the large memory to accommodate a large pattern, and also potentially using the large memory for data tables to help the calculations along.

Perhaps particularly attractive and pressing is the in-machine editing and assembly of large sources. I'm not sure of the average ratio, but source code is much bigger than object code, so it's relatively easy to fill a large memory space with source which makes a program that isn't especially large. And the code for the editor has to go somewhere too.

It's certainly attractive to have some setup whereby the code under development can't trash the state of the machine. A dual-machine setup, possibly even something like the Beeb's coprocessor architecture, is one way to achieve that.

Having large graphics buffers not get in the way of other uses of the machine is also a clear win. Again, Acorn's Master does that, as do many other machines.

Fuzix is another use-case: a small unix-like multitasking OS. Not quite ready yet, I think.

For 65C02 systems:

1) Prince of Persia like on the Apple IIe.

2) Apple IIe replica. Basically a IIe that had 128K onboard with a few enhancements. Not all of the slots. Just a "compatible" computer that would run 80-90% of Apple IIe software.

3) GUI based OS


65C816 systems:

1) GUI like the original Mac OS (basic icons, finder, menus, etc.)

2) Minimal games console using a '816, Propeller for audio/video and SRAM.

3) See # 1. I really want this.

_________________
Cat; the other white meat.

But GEOS doesn't require an '816.

Nor does Jonathan Halliday's GUI for Atari 8-bit which is a lot faster, and multitasking. It's not finished, and it does take more than 64K, but the video demos are very impressive! See http://atari8.co.uk/gui/

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

However, doing it on an '816 could produce a higher level of performance, especially in manipulating graphics.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I'd love to build something like an original Macintosh based on the '816, but I'm only new at this, so I don't have the skills to do it. It would also probably require custom hardware or a CPLD implementing that hardware.

I'd prefer something different for selecting word size than the '816, but my vision of (read: wishlist for) a 16-bit 65xx-style processor is quite a bit different to both it and the 65Org16(as I understand them, anyway).

This is my dream as well. When I read the stories over at http://www.folklore.org/, I imagine myself in that environment...creating a new platform**, but using the '816. Burrell used PAL's for much of the Mac....so using modern CPLD's would be nice. I know all of this could be done in one FPGA. That's not the point.

But to stuff a small SBC in a case like the original Mac, running a new GUI based on the '816....with a small VGA monitor....man...that's the dream.


** YES...I know that Apple didn't create the GUI platform....but it's hard to argue that they didn't push the GUI out to the "masses" first.

_________________
Cat; the other white meat.

It's faster for two reasons:

1) Atari 8-bits have a flat frame buffer, while Commodore 64 and Apple II machines have non-linear addressing. C64/C128 in particular uses character cell addressing (meaning adjacent bytes are actually 8 bytes away), and Apple II uses a bizarre form of addressing that is, in fact, related to the DRAM refresh circuitry used on the original computers.

2) Atari 8-bits have a faster CPU (1.79 MHz minimum, versus 0.98 MHz for PAL C64, 1.02MHz for NTSC). It makes a difference.

Of course, having more than 64K of memory is a big help too, since it doesn't have to swap to disk; GEOS has .... 24KB (!!) left after the system and all drivers are loaded. Let that sink in for a bit.

A high-performance 65816-based GUI does exist. Two of them, in fact. One is GS/OS for the Apple IIgs, and the second is Wheels 64/128, a 65816 port of GEOS 64/128 that is apparently fast enough to support video playback if you pre-decode the MPEG file first.

It's not really about swapping to disk. Having 128KB+ means that it can store lots of pre-shifted graphics and masks, as well as per-window + per-line span information that it can keep cached.

There's a ton of memory vs speed tradeoffs that you simply can't afford to make in 64KB.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor