Chain-Q wrote:Peter wrote:Recently I had a short but fascinated look at NetBSD/68k, because it supports a plain 68000 target with a primitive MMU. And not only that, but it even has a complete distro - which would save much work compared to Linux if I want it on the Q68. (Easier to add a primitive MMU than dealing with ucLinux.)
That sounds interesting. What is this primitive MMU? Because the Linux/68k guys are trying to "beat" some sense into the Vampire/Apollo core people, to support some kind of MMU, so they can run Linux on the thing. I'm not a big fan of the Vampire for several reasons, but regardless, if there's a shortcut for them to still get something working that might be interesting for the whole m68k community.
My idea was inspired by the Sun-2 series, which is already supported by NetBSD. It used a 68010 CPU with a proprietary external Sun-2 Memory Management Unit (MMU). I did not find full documentation of that MMU, but what I saw, was potentionally much simpler to implement than the later Motorola MMUs. For various reasons (e.g. inclusion of some retro QLers) I want the keep the CPU core (a TG68K.C) running as 68010 eqivalent for now. So the Sun-2 approach would be nearest to the current architecture.
As for Vampire, the Q68 is far from that speed, although I'm a little proud to have the TG68K.C at 40 MHz on a low-speedgrade 10 year old FPGA. Linux on a Q68 would only be a gimmick - for real fun I'd have to design some sort of Q60 successor. I'm not working on an MMU for the Q68 at the moment, cache and varirous other projects have higher priority, when there is a little spare time at all.
Chain-Q wrote:But I checked the Q68, it's a nice little board, I like it. Lets see later how this goes, and thanks for the possibility/offer/mention regardless.
You're welcome and thanks. The Q68 was more an artwork, than just a functional design. A high frequency layout with SDRAM and ethernet on a two layer PCB. It is QL specific inasmuch it is tailored for what QL drivers could likely support, and being manufactured in very small numbers. Lets see how long you remain interested in the QL, and at which point some QL hardware makes sense. I'm working on some new stuff also, but no decisions yet on releasing them. I have a functional board with medium size Lattice ECP5 FPGA and VRAM separate from main SDRAM, just so you know the direction.
Maybe 64? It certainly works for single-person projects, but it's not fast.
64 MB instead of 32 MB would just be a placement issue. But to be honest, I find a native compiler is not needed at all. Running the compiler and other development tools inside a QL emulator is totally pointless as it only brings disadvantages over running them directly. And native hardware is too slow. Investing time toward graphics/GUI support, would in my opinion be more helpful.
It is Windows software now, but I try to ensure that it plays nice with WINE. The bundle was made by a user using WineBottler I think. Alternatively there is also SMSQmulator, which has a similar feature set (but 68000 only IIRC) and was written in Java (blargh 
)
To put it another way, whatever he's doing requires such intimate familiarity with the compiler behavior and the corner-cases of the language that only a very few people can master on this level, especially in everyday work, and while working in a large team. At least the code he writes is certainly write only. I challenge anyone to understand _why_ the code was written that way, what are the assumptions it makes about compiler behavior, then modify it, just by reading it without his explanations.