I think that could work, but requires inspection of LIC, which varies between 6809 emulation and native 6309 modes, pretty horrid. Manual setting of fuse by OS code strikes me as nicer and more flexible. I’d rather update the OS in EPROM than reprogram the FPGA if I switch out processors.
I’m also quite interested in the idea of discrete fuse / unfuse registers, to allow a temporary switch to the user process map and back again… That way some of the horrid cross process space accesses that need to be done when system calling to get OS call postbyte, adjust return addresses or place return value stack frame entries etc, could be done very fast. Original OS9 L2 systems sometimes had ways of doing some of this stuff faster, but a fuse/unfuse, could be a very big win I think.
I don’t think Dave’s (@hoglet’s) current designs have any fuse idea, although I know some of the more sophisticated MMU chips do. (A fuse being a means of counting down to a delayed switch of the mapping.)
I did think that having a register which reads as an RTI (or RTS) opcode with a side-effect of changing the mapping might be a neat idea, but I don’t think it’s been tried.
George Foot’s recent dual-map 6502 project uses the idea of triggering on execution in zero page: in one iteration, the four quadrants of zero page would set four different mappings. By careful placement of short stubs of code, he could do everything he needed, in his case using the Acorn MOS ABI. He has one big switch of nearly 64k of RAM, with the crucial nicety that the 6502 stack in page 1 is common.
Dave’s code looks to be detecting vector fetch as a way to enter the system task, but the difficulty is then, how do you neatly get back to an interrupted user process space? Trampolines place irritating requirements on the memory organisation for the user task, whereas fusing instead allows setting just the stack pointer to the destination process context and then ‘RTI’ once the appropriate fuse value has been written.
This project has slightly stalled, for no good reason other than other projects are of more interest at the moment. The PCB is just about ready to be sent off, I just need to spend a few hours checking foot-prints.
The switch to a CPLD is to give use the flexibility to try out different approaches to hardware task switching without having to spin the board. The PAL based designs (which still exist on the two_pals and three_pals branches) were not flexible enough.
The current CPLD switches in/out of user mode as follows:
if (access_vector) begin
//DB: switch task automatically when vector fetch
U <= 1'b0;
end else if (RnW && mmu_reg_access && ADDR[2:0] == 3'b011) begin
//DB: switch task automatically when access the MMU's "RTI" register
U <= 1'b1;
end
Any vector fetch will cause an immediate switch to system mode, such that the vector is fetched from the system process space. The OS can then to user mode by JMPing to an RTI instruction that’s held in a read-only MMU register.
Neat idea. I can imagine it would work, but haven’t heard of a similar approach before.
If you’re prepared to sacrifice more address surface for the mmu you could make a general purpose version that runs an instruction in user task map then RTS, which would be useful.
dt1802 I explored three options for developing the Microchip/Atmel CPLDs in Verilog:
A 30 day eval licence of Atmel’s Pro Chip Designer (that uses Mentor synthesis) running on Windows
Altera Quartus 13.1 generating a POF file then the Atmel pof2jed tool running on Linux (pof2jed under Wine)
Open source Yosys generating an EDIF netlist then the Atmel ATF15xx fillter running on Linux (the fitter under Wine). This uses a technology library I put together by observing how the Mentor flow worled. This toolchain/library is available in a github repository here.
I concluded:
Is not viable for me long term, because a license costs significant $ PER YEAR
Is not great because I have low confidence in pof2jed because of the warnings it produced on my designs.
Looks the most promising but is currently untested on real devices
Getting back to user space from an interrupt is annoying anyway because you’ve got to deal with stuff like “user put the stack pointer into the I/O space”. 65C02 is easier because the user can’t do that 8)
There’s been substantial progress - @hoglet was able to put together a design which fits in 100mm square (a good value size) and get it made up - and it works! Here are the parts before assembly:
There’s a bus connector on one edge, to which we could fit peripherals, or memory, or a bus analyser. On the opposite edge there are two serial ports and an SD card interface.
It runs Fuzix, with 8k or 16k pages, and it runs @dominicbeesley’s BBC Basic. There’s a bootloader or machine monitor program which is a work in progress.
(Photos by @hoglet. Thanks to both for the hardware and software!)
At present the SD card holds a smallish Fuzix filesystem image - see the wiki.
Of course, the SD card is a hardware facility: it’s down to the firmware and software as to how it is used, and that’s something which can evolve. If one went in an Acorn direction, the firmware would include one or more filesystems which applications could use, and those filesystems could live on the SD card, or over a serial connection, or something else.
The full-fat MOS (that @dominicbeesley is developing) is based on the Acorn MOS, so supports paged/sideways ROMs that provide additional OS facilities, like file systems
He already has one existing file system ROM running: HostFS which uses the second serial port to talk to a file server running on a remote machine. So it’s already possible to load and save programs from BBC Basic.
It may be that we also try to port MMFS, which is another exiting file system that uses the SD Card, but that’s a fair bit more work, unless anyone knows of a mechanical 6502->6809 translator.
And the Fuzix side supports PC partition tables and can be taught others so it can certainly be made to share with another OS.
I suspect NitrOS/9 would be interesting on this setup too.
You also probably want to sync up to the upstream tree a bit. There bank16k code in particular has been somewhat reworked to deal with gcc 6809 being a buggy mess, at least until I can switch to a less buggy compiler
