home bbs files messages ]

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