Just to let you know, I tested the Z80 and it was broken: https://acassis.wordpress.com/2022/01/14/testing-nuttx-rtos-on-z80-simulator/
As Mr. Greg commented in this post, the guilt was this commit: https://github.com/apache/incubator-nuttx/commit/67ec3d7926d871c515fb1a55a11da8630fe53649 If I go back to commit 554d56b8752119ade4411cde9dbc1dfc5fdb8ac0 (and move apps repository to a commit around this date) the compilation works: $ ./tools/configure.sh z80sim:nsh $ make menuconfig (maybe you need to remove some apps/ new directories left behind) $ make Complete build log is here: https://pastebin.com/raw/JMfXif3H I tried to use the z80sim Release 1.37, Copyright (C) 1987-2021 by Udo Munk, but it doesn't appear to run: $ z80sim -z -x nuttx.hex ####### ##### ### ##### ### # # # # # # # # # # ## ## # # # # # # # # # # # # ##### # # ##### ##### # # # # # # # # # # # # # # # # # # # # # # # ####### ##### ### ##### ### # # Release 1.37, Copyright (C) 1987-2021 by Udo Munk CPU speed is unlimited, CPU executes undocumented instructions Loader statistics for file nuttx.hex: START : 0000H END : FFFFH LOADED: 0000H (0) Op-code trap at 6edd: ed 19 PC A SZHPNC I IFF BC DE HL A'F' B'C' D'E' H'L' IX IY SP 6edf 6e 000000 00 11 e5dd 77de 6edd 7808 4f5e 2e17 c99e 0821 95d6 873b >>> Maybe this hex file need to be converted to .bin before executing, the README.txt say nothing about the z80sim used (seems to exist more than 1 z80sim around) and don't say how to run it. BR, Alan On 1/10/22, Xiang Xiao <xiaoxiang781...@gmail.com> wrote: > Even no people complain about the inline usage, but it's always good to > isolate the inline keyword in compiler.h like others. > > On Tue, Jan 11, 2022 at 4:37 AM Petro Karashchenko < > petro.karashche...@gmail.com> wrote: > >> Following the discussion related to the "inline" keyword usage in common >> code. I have done draft changes in >> https://github.com/apache/incubator-nuttx/pull/5201 with an approach that >> possibly can be used to get rid of "inline" in common code. >> But I'm not even sure if this is needed to anyone, since there are no >> reports about compilation issues for any of the supported platforms. This >> means that the platforms are either not used (projects not updated to the >> latest NuttX release) or all used compilers support "inline" (and maybe >> C99). >> I would appreciate it if people can give feedback should I continue >> changing 7000 other places, or just drop this activity. >> >> Best regards, >> Petro >> >> пн, 10 січ. 2022 р. о 17:17 Nathan Hartman <hartman.nat...@gmail.com> >> пише: >> >> > On Mon, Jan 10, 2022 at 9:15 AM Gregory Nutt <spudan...@gmail.com> >> wrote: >> > > >> > > > >> > > > Speaking of the Z80, would it be possible to run NuttX in a Grant >> > Searle >> > > > / RC2014 platform with a 8k ROM /56k RAM split, or would any >> > > > attempt >> > > > require banked memory? >> > > > >> > > >> > > I don't know if it is possible or not. I don't know if NuttX is >> > > viable >> > on >> > > any CPU limited to a 64Kb address space. In their day, those 8-bit >> CPUs >> > > were programmed in highly tuned assembly language. it is hard to >> imagine >> > > running an OS that is almost as big as the addressable memory and >> > > being >> > > able to do anything meaningful. NuttX may have outgrown these >> platforms. >> > > >> > > I think that z80 architecture support is still important because >> > > there >> > are >> > > so many derivatives from z80, like that FPGA in the ZX Spectrum Next >> > > ( >> > > https://en.wikipedia.org/wiki/ZX_Spectrum_Next). That FPGA runs the >> z80 >> > > with a extended address space using an MMU similar to the z180 but >> > > with >> > > smaller pages. Other derivatives like the z300 and the ez80 just >> > support a >> > > wider address space. I have done a couple of ezo ports recently >> > > (like >> > > http://z20x.computer/). >> > > >> > > I appreciate this discussion about protecting the NuttX supported >> > platforms. >> > >> > I think non-arch-specific code should stick with C89 and we should not >> > be too eager to remove architectures that have these needs. >> > >> > It's not too hard to tell people that non-arch-specific code needs to >> > be >> > C89. >> > >> > We can catch it more easily in precheck by passing the C89 flag to the >> > compiler. >> > >> > Only in the case where an architecture is incomplete, unmaintained, >> > and NuttX isn't really viable for it anymore, should we consider >> > removing it. >> > >> > We should have a rule that removing an arch should require a process >> > that makes it highly likely that we'd hear from any users who consider >> > that arch important. >> > >> > For example, get the word out for some period of time and solicit >> > feedback. If no feedback, then mark the arch deprecated, produce >> > build-time warnings, require users to activate some kind of >> > CONFIG_DEPRECATED_ARCH to use it. In other words, do things to get >> > their attention. And then, have a mandatory waiting period to allow >> > enough time to either attract maintainers or be able to declare the >> > arch dead with a clear conscience. >> > >> > > > So many RTOS are just for arm. >> > >> > The whole point why I adopted NuttX is because of being able to move >> > my applications from one arch to another. >> > >> > > Originally, NuttX was focused on the hobbyist, DIYer, and >> retro-computing >> > > enthusiast. But nowadays, it is dominated by businesses with business >> > value >> > > systems that are sometimes not compatible with the needs or interests >> of >> > > hobbyists. That is why there is such a long discussion in the >> > > INVIOLABLE.md under "All Users Matter." That was essentially the >> > contract >> > > I made when I agreed to give the OS to the community. But it is >> > > going >> to >> > > take some strong leadership to keep those values since the OS is >> > controlled >> > > completely by businesses now and businesses tend to think only of >> > > their >> > own >> > > needs. >> > >> > We need more hobbyist/DIYer committers and PMC. >> > >> > We need a short and professional presentation, targeted specifically >> > to business users, that clearly explains why it is in their best >> > interests to play nice with the community. >> > >> > Cheers, >> > Nathan >> > >> >
