Thoughts about a longer-term roadmap

[sy2002]

Thoughts for a longer-term roadmap:

V1.6

• MEGA65 support incl. HDMI and HyperRAM
• Interrupts incl. Timer
• Stabilizations/optimizations/cleanup

V1.7: Make QNICE-FPGA a retro multimedia machine: ETA Winter 2020/2021

• Multicolor VGA incl. softscrolling and sprites
• Music synthesizer chip(s)
• Networking
• Cool demos/games

Michael, you could do the Yamaha, I would be interessted to do the (double) SID. Would be great, if you could do the Networking, because the consumer version of the MEGA65 does have networking but no serial port (only if you attached a JTAG on the board, which is what I am currently doing). So loading files could than have an enhanced "qtransfer" that uses Ethernet.

We should take our time for 1.7 and also invest time in some really cool demo programs, so I suggest to release it somewhere around Christmas or early next year. If we also want to do the architectural cleanup stuff, then we need a lot of debugging and therefore also the on-system debugger. If we want to move that to V1.8, then also OK for me.

V1.8: Becoming a real computer: ETA Summer 2021

• Writeable SD Card, Writeable FAT32
• Being able to write assembler code directly on QNICE (needs editor, assembler).
• MMU
• User/kernel mode
• (Maybe, because this is a large project in its own): Pipelined CPU
• (If and when Pipelined architecture): 100 MHz

This issue is connected with issues #80 and #94

[bernd-ulmann]

I completely agree and would love to see a MMU and Ethernet adapter in v1.8. :-)

Do we want a user/kernel mode feature or do we think of benevolent users/programs and just keep everything in one CPU mode? What do you think?

Something like XINU should run without user/kernel mode support.

[MJoergen]

I already have implemented Ethernet support on the Nexys4DDR in two other projects.

In one project I have a simple I/O register map just like the VGA module, i.e. an address register (with auto-increment) and a data register. This design is relatively simple, and I have written software for this (in 6502 assembly).

The other project uses a simple DMA where received Ethernet frames get written to a buffer directly in the main memory. This is more complicated to implement in hardware, and I'm not sure the (limited) benefit is worth it.

All this just to say I would like to add Ethernet support to V1.7 release, at least if we go with the simple design in the first project mentioned above.

[bernd-ulmann]

Just a weird thought about DMA: Since QNICE has a 16 bit address space, we find ourselves in the same situation as the PDP11 where (at least in all but the smallest models) the physical memory space is larger than the logical space. Couldn't we (just thinking "loud") have our MMU not only map 8 8kW pages to the logical CPU address space but also map any page to an IO controller such as the Ethernet controller? We could make sure that no page is mapped to the CPU address space and the Ethernet controller simultaneously and the operating system just had to swap a page containing an Ethernet packet for another page which is currently mapped into its address space.

What do you think?

It would be, of course, much simpler if the Ethernet controller had on-"board" memory holding the last packet which would then be transferred under software control to the main memory but this would require a loop while the MMU-DMA-version would only require to remap a page.

[MJoergen]

This sounds like an interesting architecture. This MMU will provide a lot of benefits I see now. We really need to get together and talk through all these ideas.

[sy2002]

Excellent thoughts, gentlemen.

As the MMU would be part of V1.8 and Ethernet is supposed to be part of V1.,7, I suggest that Michael implements the simple version of the Ethernet and we might want to enchance it by DMA in V1.8.

Do we want a user/kernel mode feature or do we think of benevolent users/programs and just keep everything in one CPU mode? What do you think?

Good point, Bernd! I would opt for having a user/kernel mode, as V1.8 is dubbed "becoming a real computer" 😄 So I added "user/kernel mode" in the above mentioned list for V1.8

Couldn't we (just thinking "loud") have our MMU not only map 8 8kW pages to the logical CPU address space but also map any page to an IO controller such as the Ethernet controller?

This is an awesome idea and we should do exactly that! Because then, we could also map VGA address space and have really fast graphics and full-screen animations ;-) So I guess, V1.8 will become an interessting package, too.

[bernd-ulmann]

Since a MMU and user/kernel mode are pretty inseparable, we should implement both in v1.8 and have a simpler Ethernet interface in v1.7. :-)