Dragon MMU solutions ...

[tjewell]

Hi all! There was much talk of MMUs at this year's Meetup (a particularly good one I thought this year!), so I was wondering if someone might take a stab at summarising the different options in a way that even simple people like me could understand.

The options I can see if you want to go beyond 64K at the moment are Sixxie's SamX, Stew's 256K Banker (and Julian's version thereof) and the CocoMEM Jr (which I've only just discovered). There's also older solutions like Tormod's Mooh (which is no longer easily available), the DragonPlus (which gives you 128K, but is more about the 80 column screen) and the period veroboard solution that JohnW was showing at the Meetup, but I'm not entirely sure the status of.

Can anyone quickly summarise these? I guess it would be good to understand OS-9, Flex and Fuzix support, plus a feel for how Dragony these solutions are, as that seemed to be an important metric at the Meetup

Cheers! Tony

[sixxie]

Here's the SAMx8 manual, which obviously describes what it can do, but has a section on the last page going through some other projects I knew of at the time, and summarises a few pros and cons:

http://www.6809.org.uk/dragon/samx8/doc/samx8.pdf

I think Jim Brain (Go4Retro on here) said his project does interface to video, but I can't remember how. Maybe interposes the SAM as well as the CPU.

Edit: others can better comment on OS-9 suitability of them all, but I reckon SAMx8 fits Fuzix pretty well, as I had it in mind when making it

[Go4Retro]

Hi all! There was much talk of MMUs at this year's Meetup (a particularly good one I thought this year!), so I was wondering if someone might take a stab at summarising the different options in a way that even simple people like me could understand.

I'm happy to see the interest.

The options I can see if you want to go beyond 64K at the moment are Sixxie's SamX, Stew's 256K Banker (and Julian's version thereof) and the CocoMEM Jr (which I've only just discovered). There's also older solutions like Tormod's Mooh (which is no longer easily available), the DragonPlus (which gives you 128K, but is more about the 80 column screen) and the period veroboard solution that JohnW was showing at the Meetup, but I'm not entirely sure the status of.

I have reproduced the BankerBoard 512kB, which should fit in a Dragon jsut fine (though, I created an SRAM replacement that spans the DRAM sockets to make it easier to build, so I need to make a span PCB for the Dragon variants).

As for CoCoMEM Jr (Thinking of changing the name, since it looks like the Dragon might be the first to actually get it going, and it's not CoCo-unique, just needs a 6809E), I sent one to Pere along with a CPLD programmer, so hopefully he can make use of it. I've been searching for almost 10 years to find someone to help me get OS9LII running on it. I'm happy to send a few others out (need to solder them up) if there is serious interest in getting OS9L2 working. I know that's not the end of the road, but that's what everyone will ask first: "Does it run OS9L2?"

Can anyone quickly summarise these? I guess it would be good to understand OS-9, Flex and Fuzix support, plus a feel for how Dragony these solutions are, as that seemed to be an important metric at the Meetup
Cheers! Tony

Hmm, someone will have to clue me on on how one makes something "Dragon-y". I admit my name currently fails that, but that's not too hard to change. Not sure about other stuff.

Jim

[Go4Retro]

I think Jim Brain (Go4Retro on here) said his project does interface to video, but I can't remember how. Maybe interposes the SAM as well as the CPU.

My effort is a work in progress, but it currently creates a "hole" in the address space for pages 38-3f and passes memory requests to those memory locations on the main motherboard (which means video must be located in 1 64kB bank)

I also played around with have a daughterboard that moves the memory to the motherboard, and has a few "flying leads" to connect the CPU PCB to the memory PCB. This would allow video to access all available memory, but it has a few drawbacks:

• Second board to deal with
• extra wires to deal with
• Not as easy to override ROM reset vectors (I don't think it's impossible, just force the address to change when $fffx is accessed, but it's not as trivial as with on board RAM
• RAM must be accessed at regular speed (not a current issue, but having on board memory offers the potential to run the CPU faster and only slow down for external memory accesses

Of course, there are upsides:

• video memory expanded
• Can support BankerBoard functionality if desired
• Easier solution for Dragon32 (non memory PCB option means main mobo needs 64kB already or needs to be updated to have 64kB)

And, I also tried out a solution that offered both (so, onboard "fast memory" and motherboard "slow" memory). That's a bit of complexity, though, so it needs to be worth it to do that. Pere's test unit has provisions to implement the motherboard RAM expansion, at least up to 1MB, if that's the path to go.

Jim

[bluearcus]

I'm not really clued up on the CoCoMemJr's feature set or low level implementation details, but for the other memory expansions I can put together a comparison.

Generally, these things fall into a couple of different groups:

There are 'additional offboard memory' and 'on mainboard memory upgrade' approaches.
There are bank switching only, and fully paged MMU designs.
There are designs that are CPU daughterboard hosted, SAM daughterboard hosted, cart port hosted and no socket fitting internal add-on boards.
The vast majority of the true MMU designs use 8k pages and two task maps like the CoCo3 (currently).
The true MMU designs don't tend to provide process isolation - FF00 page and a FE00 trampoline / soft vector page are available in all tasks, not just to the system task.
Emphasis is always in these designs on expanding RAM, rarely is there additional ROM storage capability.

How Dragon-y something is, is - of course - largely subjective. I personally think RAM belongs on the mainboard, and that Dragon data thought that 4k with 16 tasks and a 1Mb address space was a good shape. 8k pages are a CoCo3 horror that were not even considered supported by Microware before Tandy twisted their arm.

Also, any modern design that would have been impossible in 1987 probably loses some marks.

Spreadsheet incoming later.

Mike

[Go4Retro]

For your spreadsheet:

CoCoMEM Jr replicates the CC3 MMU (8kB pages, multiple tasks, optional common memory at $fexx, etc.)

It currently sits in the CPU socket

The HW design supports 14 bits of MMU address extension (128MB of linear address space) with 2 "special" bits reserved for memory protection, with an optional interrupt on write to a read-only page)

The HW supports 32 hardware tasks and multiple task groups. The current firmware does not enable those functions, for ease of base functionality testing.

The HW and firmware maps the onboard Dragon 64kB into 8kB pages $8-$3f)

I agree with 4kB pages (make nomenclature easier, as the highest nybble of the address is the MMU nybble, and it makes MMU calcs easier to dereference).

[bluearcus]

OK, don't bite me...

https://docs.google.com/spreadsheets/d/ ... ingle=true

[bluearcus]

And for completeness, the non-Dragon-y 6809 MMUs are largely documented here:

https://haserin09-la-coocan-jp.translat ... r_pto=wapp

With some more info on some of these machines (and a few others, some with, some without memory above 64k) here:

https://www.sardis-technologies.com/oth6809/oth6809.htm

[Go4Retro]

OK, don't bite me...

https://docs.google.com/spreadsheets/d/ ... ingle=true

Hehe.

A few notes on CoCoMEM Jr:

Full specifications and technical info not available, but video memory access is problemmatic. ... As per the Mooh fix, requires specific page / pages to be used when mapping video RAM, but shouldn't require reservation in all task maps.

True, it does not require same reservation in all maps. Just the task that writes to Video.

It's unclear how much of a pain the VDG memory access problem will turn out to be on this design. Fundamentally the problem is similar to that experienced by the Mooh, although direct control over CPU line outputs to the main board might remove the need for a standalone SAM !EXTMEM write inhibit change, and flying leads to the mainboard.

The current firmware switches any write to non-motherboard memory to a read, which protects motherboard RAM from erroneous writes.

You might want to include the URL to the repo: http://github.com/go4retro/CoCoMemJr

Also, I also created a replacement for the BankerBoard, called the Banker+. It's equivalent to the Banker in functionality and supports up to 512kB. It uses a small SRAM module to provide the 512kB:

https://github.com/go4retro/BankerPlus

[Julian]

Can I throw my interpretation in the mix then? Not *just* MMU, this is a replacement for SAM, RAM, ROM and VDG

Using the SAMx8 as a starting point I have the usable RAM expanded to 2MB using 8K page sizes. The pages are allocated against 4 "tasks", a supervisor, two operational tasks and the video system. Pages can be protected or shared (so video ram can be addressed by any task)
The ROM space is a flash ROM with an address space the same as the RAM - any 8K rom page can be mapped into the task pages. I'm still working on it but it should be possible to use the same device as a fixed disk (equivalent to a single 5.25 floppy). By default the ROM mapping is to place the last 8K page into the top of the 64KB address space, this can obviously be overridden to suit the application but the 16 byte vector table can be controlled at the task level per vector. The RESET, NMI and (if using a 6309) ERROR vectors remain under the control of the supervisor regardless. The cold start vector will always be as specified in the last page of the ROM

I've limited the design to using just 2MB of RAM but in theory it could be expanded beyond that, likewise for the ROM space

The differentiator here is the same device incorporates the VDG as well, enabling the CPU speed to be flexed independently of video operation, so a HD63C09 can actually run full speed while still maintaining video (and compatibility with slow devices).

The system is based around the Altera/Intel MAX II CPLD but can be adapted to work with any suitable CPLD or FPGA device, it just needs enough IO pins and internal resource (going off topic, I have a full FPGA core version that includes a fast 6809 that can run in place of, or independently of, an external CPU, at up to 40MHz when using regular SRAM)