Forums before death by AOL, social media and spammers... "We can't have nice things"
|    alt.os.development    |    Operating system development chatter    |    4,255 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 3,753 of 4,255    |
|    mutazilah@gmail.com to Dan Cross    |
|    Re: PD computer    |
|    03 Apr 23 17:04:12    |
      From: muta...@gmail.com              On Tuesday, April 4, 2023 at 2:07:30 AM UTC+8, Dan Cross wrote:              > >I'm not using "mips open deliverables".              > I'd re-read that if I were you. Note that they refer to the        > _instruction set architecture_. You seem to be confused about        > what precisely this citizen computer thing is actually referring        > to: that is an implementation of a MIPS soft-core on an FPGA.        > That's quite different from the ISA being in the public domain,        > though.              Again - copyright covers a work of art. Not an       architectural concept. Patents could cover the later.       But 20 years have passed.              > >Copyright covers some artistic work, which their        > >deliverables will be, but I don't think they can copyright        > >the instructions themselves. That's more like a list of        > >names.        > >        > >They could patent them though if there was something        > >novel about them. But any relevant patents expired long        > >ago. That Plasma project deliberately avoided including        > >some instructions because at the time there were still        > >some applicable patents.              > There's a lot more to the CPU than _just_ the instruction        > mnemonics: memory and IO architectures, how interrupts work,        > how encodings and a whole lot more.               That's not a work of art covered by copyright.              > Anyway, the point here is that the MIPS is not a "PD        > processor." Be careful with how you describe it,        > especially as MIPS is particularly litigious.              I didn't say that "MIPS is a PD processor", if that even       has a meaning.              What I said is that the VHDL produced by the Plasma project       has been released to the public domain.              So we have a public domain CPU available. In my       understanding of the law, the MIPS company can't       stop me taking that VHDL to a manufacturer and       getting chips produced, and selling them.              That by itself wouldn't avoid patents though.              But the 20 year wait has avoided patents.              I may not be able to call it MIPS either, as that is a       trademark. But that's a different issue from both       copyright and patent. And I don't care about having to       rename it. It's a subset anyway (the unaligned access       instructions don't exist - but I don't care about that       either).              > >> >But PDOS-generic doesn't care about that.        > >> >        > >> >The PD tools I am using may need to change though.        > >> >At least the assembler.        > >> >        > >> >I do need a pseudo-BIOS for pdos-generic to run under,        > >> >and I am wondering how many lines of code that would be.        > >        > >> Lots.        > >        > >Note that we will be using PS/2 for the keyboard to        > >avoid needing a USB stack.              > Doesn't matter. That's only a small part of what you'd have to        > write, and the impedence mismatch is large.               What impedence mismatch?              > Also note that on a lot of laptops, you don't actually have a        > physical PS/2 keyboard controller. Rather, you have an emulator        > that's implements a soft-PS/2 controller in proprietary code        > that runs in SMM mode, but that is actually talking to a USB        > keyboard on your behalf. If you yank the x86 CPU, you also lose        > SMM mode (which is x86-specific) and you lose that capability.              I think you have misunderstood what I asked for.              I'm not talking about getting an existing laptop and swapping       out the CPU.              I'm talking about creating a new laptop based around a       specific FPGA. Presumably high priced, and only of       interest to hobbyists.              With that proposal on the website I need to assemble my       own desktop.              I'd prefer to buy an expensive (within reason) laptop.              > >Jean-Marc has higher goals, but I'm only trying to get        > >to a lower goal of getting a C compiler working.        > >        > >And after that a serial port to access the outside world.        > >        > >I've written a serial port driver before, for the 8086.        > >It wasn't a lot of code.              > That's only one of many things you'd have to write, and it's        > relatively easy by comparison to many of the others.              Could you give me say the 3 most difficult things to       write for the proposed desktop?              > >> >I'm also wondering whether I can simply buy a laptop with        > >> >that FPGA in it instead of constructing a desktop.        > >> >        > >> >I'm thinking of a completely dead laptop.        > >> >        > >> >Doesn't even have a functioning processor.        > >        > >> That would almost certainly not work. A laptop mainboard is        > >> designed around a particular CPU; one cannot just swap out        > >> another CPU of a different architecture and expect it to work.        > >> For example, given an x86-based laptop, LPC peripherals designed        > >> for programmed IO would need some bridge mechanism to work with        > >> MIPS, which does not have programmed IO instructions.        > >        > >Can e.g. the serial port be dual-driven by either a memory        > >write or an IO to cover both?              > Possibly, but it depends very much on the specific UART. Often,        > these are embedded in the platform chipset, but you'll have to        > know a lot about _that_ to make it all work. Very often you'd        > have to fiddle with the platform's control apparatus in order to        > configure the UART to respond to either MMIO accesses or legacy        > IO accesses before doing either; usually the firmware does this        > for you (and these days sometimes provides a BIOS emulation        > layer). Doing this successfully requires a lot of experience        > and patience.              Ok, so the proposed laptop could be built, and cover both       memory-mapped I/O and "legacy IO".              If it's a once-off software cost, that's fine. I'm more trying       to get a flexible laptop than avoid code.              > >Or just split FPGA laptops into two broad categories?              > Trying to rip a central component out of a tightly-integrated,        > highly vertical system and replacing it with a completely        > different component without significant re-design is just not        > viable.              The proposal was for a NEW tightly-integrated system.              TWO new systems in fact. In laptop form.              Pre-made.              If one is insufficient because of MMIO vs legacy.              But it sounds like one is (probably) sufficient in       conjunction with code.              BFN. Paul.              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca