OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 10:41 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 27 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: CLI v. GUI
PostPosted: Mon Nov 02, 2020 9:13 am 
Offline
Member
Member
User avatar

Joined: Mon May 22, 2017 5:56 am
Posts: 812
Location: Hyperspace
rdos wrote:
I have a pretty advanced FPGA device that has Ethernet, Fibre interface, HDMI video interface, high speed ADC/DAC interface, USB, Micro SD-card interface, and an 8 lane PCI express interface. It's a pretty complex device on its own, but you need to program it with Verilog, and maybe a Verilog based OS is not such a good idea? :-)

Haha! A Verilog-based OS would require a totally different way of thinking, I believe.

rdos wrote:
OTOH, you could also use it as a general peripheral and then implement the OS with whatever hardware you like as long as it has 8x PCI express. That has the advantage of learning both how to create complex hardware devices and OSes. :-)

Very funny! :D

I was thinking of FPGA-based computers where the usual practice is to load one or more cores into the FPGA. See opencores.org for some examples. There are also FPGAS with CPU cores in the same package. 9front runs on one of these; a dual-core ARM with the FPGA handling Ethernet, SATA, USB, and DisplayPort. (DP wasn't fun, but required fewer pins than HDMI. HDMI would have taken the IO which was wanted for SATA.) The guy who developed the board loves C and hates Verilog. ;) He made a simpler, C-like language for FPGAs. It compiles to Verilog. I don't think he had time to finish it though. I think he likes VHDL better than Verilog, but which one you get to use depends on your FPGA manufacturer. There are no open-source compilers here.

_________________
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie


Top
 Profile  
 
 Post subject: Re: CLI v. GUI
PostPosted: Mon Nov 02, 2020 9:19 am 
Offline
Member
Member
User avatar

Joined: Tue Sep 15, 2020 8:07 am
Posts: 264
Location: London, UK
eekee wrote:
rdos wrote:
I have a pretty advanced FPGA device that has Ethernet, Fibre interface, HDMI video interface, high speed ADC/DAC interface, USB, Micro SD-card interface, and an 8 lane PCI express interface. It's a pretty complex device on its own, but you need to program it with Verilog, and maybe a Verilog based OS is not such a good idea? :-)

Haha! A Verilog-based OS would require a totally different way of thinking, I believe.



Pah! FPGAs are cheating... No point building your own hardware if you aren't building it out of 7400 series chips. [-(

_________________
CuriOS: A single address space GUI based operating system built upon a fairly pure Microkernel/Nanokernel. Download latest bootable x86 Disk Image: https://github.com/h5n1xp/CuriOS/blob/main/disk.img.zip
Discord:https://discord.gg/zn2vV2Su


Top
 Profile  
 
 Post subject: Re: CLI v. GUI
PostPosted: Mon Nov 02, 2020 9:34 am 
Offline
Member
Member
User avatar

Joined: Mon May 22, 2017 5:56 am
Posts: 812
Location: Hyperspace
Solar wrote:
Most applications also made use of "ARexx Ports", a scripting callback interface that allowed applications to "talk" with each other, or be "remote controlled" by scripts.

You know, Apple had a go at adding something like this in the 00s. I guess it didn't catch on, possibly because the scripting interface was some drag-and-drop flowchart thing. I was actually confused to the point I never got to try it, but then I was busy with a lot of other things at the time. I don't want to try it now; I don't fancy installing OS X 10.4 or 10.3 on the CF card my Mac uses for a disk now. 10.4 gets pretty swap-heavy on that little thing, and 10.3 crashed more than it ran!

_________________
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie


Last edited by eekee on Mon Nov 02, 2020 9:42 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: CLI v. GUI
PostPosted: Mon Nov 02, 2020 9:41 am 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3191
eekee wrote:
rdos wrote:
I have a pretty advanced FPGA device that has Ethernet, Fibre interface, HDMI video interface, high speed ADC/DAC interface, USB, Micro SD-card interface, and an 8 lane PCI express interface. It's a pretty complex device on its own, but you need to program it with Verilog, and maybe a Verilog based OS is not such a good idea? :-)

Haha! A Verilog-based OS would require a totally different way of thinking, I believe.

rdos wrote:
OTOH, you could also use it as a general peripheral and then implement the OS with whatever hardware you like as long as it has 8x PCI express. That has the advantage of learning both how to create complex hardware devices and OSes. :-)

Very funny! :D

I was thinking of FPGA-based computers where the usual practice is to load one or more cores into the FPGA. See opencores.org for some examples. There are also FPGAS with CPU cores in the same package. 9front runs on one of these; a dual-core ARM with the FPGA handling Ethernet, SATA, USB, and DisplayPort. (DP wasn't fun, but required fewer pins than HDMI. HDMI would have taken the IO which was wanted for SATA.) The guy who developed the board loves C and hates Verilog. ;) He made a simpler, C-like language for FPGAs. It compiles to Verilog. I don't think he had time to finish it though. I think he likes VHDL better than Verilog, but which one you get to use depends on your FPGA manufacturer. There are no open-source compilers here.


I have this device: https://www.xilinx.com/products/boards- ... 705-g.html

Buying an evaluation board gives a lot of hardware, and also a limited license to their development tools which otherwise are pretty expensive.

They have a C environment they call "Microblaze", but I didn't like that too much so I wrote everything in Verilog instead. :-)

I also bought a 1G sample, 2 channel ADC & DAC from Analog devices which interfaces through the FMC connection on the FPGA board. It was a lot of work to learn Verilog, and to create an environment that could configure the ADC through a PIC device interface and then send sample data through PCI express to RAM in the target computer. I also developed a driver for my OS that created a schedule for the ADC. It all works pretty well and I can sample up to 750 MHz and then transfer the data in real-time to the host. It was a fun project where I learned a lot about how PCI is implemented in devices.

There was also a lot of problems since the reference designs used MicroBlaze and the local SDRAM of the FPGA. MicroBlaze cannot keep up with an ADC running at 750 MHz.

It would be fun to explore the Ethernet device as well, but I've not had time for it and my license to the development tools soon expires.

Besides, this device also has a huge number of DSP slices and so it's possible to do very complex signal analysis in real-time, although I think it is much easier to do this on PC hardware, and so I decided it was better to get a fast PC with lots of RAM.

Another drawback of doing things with Verilog is that it takes a VERY long time to build the code when the project is complex. Debugging also was a bit different, with adding signal tracers to the design.


Top
 Profile  
 
 Post subject: Re: CLI v. GUI
PostPosted: Mon Nov 02, 2020 9:56 am 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3191
bloodline wrote:
eekee wrote:
rdos wrote:
I have a pretty advanced FPGA device that has Ethernet, Fibre interface, HDMI video interface, high speed ADC/DAC interface, USB, Micro SD-card interface, and an 8 lane PCI express interface. It's a pretty complex device on its own, but you need to program it with Verilog, and maybe a Verilog based OS is not such a good idea? :-)

Haha! A Verilog-based OS would require a totally different way of thinking, I believe.



Pah! FPGAs are cheating... No point building your own hardware if you aren't building it out of 7400 series chips. [-(


:-)

True. I've built stuff with those. However, then I went on with Microchip microcontrollers, and now I prefer FPGAs for anything more complex. :-)

I've built a few hole-mounted PCBs and then got them professionally manufactured with the help of Macaos, but soldering something containing a complex FPGA is not for me. I also avoid surface-mounted stuff. That's why evaluation boards are a good alternative. You get av ready-made PCB with all the components soldered and everything is tested with reference designs.

Still, it is fun to build everything yourself. :mrgreen:


Top
 Profile  
 
 Post subject: Re: CLI v. GUI
PostPosted: Mon Nov 02, 2020 10:29 am 
Offline
Member
Member
User avatar

Joined: Mon May 22, 2017 5:56 am
Posts: 812
Location: Hyperspace
rdos wrote:
I have this device: https://www.xilinx.com/products/boards- ... 705-g.html

Buying an evaluation board gives a lot of hardware, and also a limited license to their development tools which otherwise are pretty expensive.

They have a C environment they call "Microblaze", but I didn't like that too much so I wrote everything in Verilog instead. :-)

I also bought a 1G sample, 2 channel ADC & DAC from Analog devices which interfaces through the FMC connection on the FPGA board. It was a lot of work to learn Verilog, and to create an environment that could configure the ADC through a PIC device interface and then send sample data through PCI express to RAM in the target computer. I also developed a driver for my OS that created a schedule for the ADC. It all works pretty well and I can sample up to 750 MHz and then transfer the data in real-time to the host. It was a fun project where I learned a lot about how PCI is implemented in devices.

There was also a lot of problems since the reference designs used MicroBlaze and the local SDRAM of the FPGA. MicroBlaze cannot keep up with an ADC running at 750 MHz.

It would be fun to explore the Ethernet device as well, but I've not had time for it and my license to the development tools soon expires.

Besides, this device also has a huge number of DSP slices and so it's possible to do very complex signal analysis in real-time, although I think it is much easier to do this on PC hardware, and so I decided it was better to get a fast PC with lots of RAM.

Another drawback of doing things with Verilog is that it takes a VERY long time to build the code when the project is complex. Debugging also was a bit different, with adding signal tracers to the design.

I thought it would be something like that. I like eval boards too. Did the display on it help with debugging at all?

CPUs implemented on FPGAs have a reputation of being a bit slow, which would explain your troubles with Microblaze. They're fast enough for Amiga-era hardware, but I guess if you wanted to do your signal processing on the card, you'd have to use the DSP.

Stray fact: Bloomberg do their financial computations with 100-digit integer BCD arithmetic units implemented in FPGA PCI cards. New York Stock Exchange uses floating point instead, and they just accept they'll lose shares occasionally.

@bloodline: my same friend who made the board with the ARM/FPGA made a 6502 out of 74HC. He had trouble getting it to 1MHz. ;)

But I think we're waaaay off topic now! :mrgreen:

_________________
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie


Top
 Profile  
 
 Post subject: Re: CLI v. GUI
PostPosted: Mon Nov 02, 2020 3:11 pm 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3191
eekee wrote:
I thought it would be something like that. I like eval boards too. Did the display on it help with debugging at all?


No. You cannot even see it when the card is fitted in a typical computer. The eight LEDs are enough and easier to use. For serious debugging, logic analyser components are added to the design. Alternatively, the PCI bar and memory contents could be viewed from the OS side.

eekee wrote:
But I think we're waaaay off topic now! :mrgreen:


I suppose, but it is an interesting topic so I might start a new topic.


Top
 Profile  
 
 Post subject: Re: CLI v. GUI
PostPosted: Mon Nov 02, 2020 8:39 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
eekee wrote:
Graphics will likely be another microcontroller dynamically generating the video signal.

Are there any microcontrollers fast enough for that? Ordinary 640x480 VGA requires a 25MHz pixel clock!

eekee wrote:
The other day, I tried to work out if I could get 1080x1920 with only 16KB video memory.

If you can squeeze 128 pixels in each byte, you're good to go. Perhaps something with tiles like VGA text mode instead of individually-addressable pixels?


Top
 Profile  
 
 Post subject: Re: CLI v. GUI
PostPosted: Tue Nov 03, 2020 1:21 am 
Offline
Member
Member
User avatar

Joined: Tue Sep 15, 2020 8:07 am
Posts: 264
Location: London, UK
Octocontrabass wrote:
eekee wrote:
Graphics will likely be another microcontroller dynamically generating the video signal.

Are there any microcontrollers fast enough for that? Ordinary 640x480 VGA requires a 25MHz pixel clock!


I have bit banged a black and white VGA signal using a Teensy 4.0 (600Mhz ARM uC). This only requires three signals (H Sync, V Sync and Video), I couldn’t get the GPIO switching fast enough to change 24 pins per pixel. I did try and even built three resistor ladder DACs on breadboards to tests it :lol:

On the Teensy forums, some members have had more success using the uC’s DMA...

_________________
CuriOS: A single address space GUI based operating system built upon a fairly pure Microkernel/Nanokernel. Download latest bootable x86 Disk Image: https://github.com/h5n1xp/CuriOS/blob/main/disk.img.zip
Discord:https://discord.gg/zn2vV2Su


Top
 Profile  
 
 Post subject: Re: CLI v. GUI
PostPosted: Tue Nov 03, 2020 2:58 am 
Offline
Member
Member
User avatar

Joined: Mon May 22, 2017 5:56 am
Posts: 812
Location: Hyperspace
New thread for graphics :mrgreen:

_________________
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie


Top
 Profile  
 
 Post subject: Re: CLI v. GUI
PostPosted: Thu Jan 07, 2021 1:26 pm 
Offline
Member
Member
User avatar

Joined: Mon Jun 05, 2006 11:00 pm
Posts: 2293
Location: USA (and Australia)
A GUI takes more effort because even after you're in the video mode itself, you need to deal with drawing fonts, navigation, layouts, etc. While a raw text mode CLI is the easiest thing because you just printf whatever and display it sequentially. For this reason, most OS's here start with a text mode CLI and most OSDev tutorials start by printing Hello World to 0xb8000.

Then you have text-based user interfaces, but I would consider these a GUI because they're still based around visual elements (buttons, windows, etc.) rather than a command-line. The fact that a TUI uses the graphics device's text-mode is an implementation detail. Likewise with graphical CLIs (terminal emulators, Mathematica, etc.) that are command-line but are implemented with a video mode.

My long term goal is a GUI and I'm thinking of having an immediate-mode style API, but until I get the basics of my microkernel down with regards to messaging and drivers, I'm keeping with a CLI because it's easy to debug.

_________________
My OS is Perception.


Top
 Profile  
 
 Post subject: Re: CLI v. GUI
PostPosted: Thu Jan 07, 2021 3:27 pm 
Offline
Member
Member
User avatar

Joined: Mon May 22, 2017 5:56 am
Posts: 812
Location: Hyperspace
AndrewAPrice wrote:
A GUI takes more effort because even after you're in the video mode itself, you need to deal with drawing fonts, navigation, layouts, etc. While a raw text mode CLI is the easiest thing because you just printf whatever and display it sequentially. For this reason, most OS's here start with a text mode CLI and most OSDev tutorials start by printing Hello World to 0xb8000.

Yeah. Designing a good GUI toolkit takes a lot of planning, and even bad ones have lots of features which need implementing. On the other hand, here's an opinion I don't let out very often: I think hardware text modes were obsolete by 1990. ;) I should probably try to come up with a tutorial on the simplest possible text rendering to graphical framebuffers if there isn't one already.

AndrewAPrice wrote:
The fact that a TUI uses the graphics device's text-mode is an implementation detail.

My thoughts exactly!

AndrewAPrice wrote:
Likewise with graphical CLIs (terminal emulators, Mathematica, etc.) that are command-line but are implemented with a video mode.

Not my thought in the slightest! ;) All that matters to me is the way you use it. If you type commands, it's a CLI. If you point or navigate to active areas, it's a GUI. I've used one program which is a true hybrid between these two definitions: the Acme text editor from Plan 9. It's powerful.

AndrewAPrice wrote:
until I get the basics of my microkernel down with regards to messaging and drivers, I'm keeping with a CLI because it's easy to debug.

That is true, especially if you have a CLI on a serial port for several reasons.

_________________
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 27 posts ]  Go to page Previous  1, 2

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 23 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group