RDT64 (Retro Dumb-Terminal) User's Manual

Total Page:16

File Type:pdf, Size:1020Kb

RDT64 (Retro Dumb-Terminal) User's Manual RETRO DUMB-TERMINAL RDT64-1 CIRCUIT BOARD USER’S MANUAL 2020.11.12 Lucid Technologies http://www.lucidtechnologies.info/ Email: [email protected] Copyright © 2020 by Lucid Technologies All rights reserved The information in this manual has been carefully checked and is believed to be accurate. However, Lucid Technologies makes no warranty for the use of its products and assumes no responsibility for any errors which may appear in this document. Lucid Technologies reserves the right to make changes in the products contained in this manual in order to improve design or performance and to supply the best possible product. Lucid Technologies assumes no liability arising out of the application or use of any product or circuit described herein; neither does it convey any license under its patent rights, nor the rights of others. RDT64, Retro Dumb-Terminal 2 CONTENTS 1.0 Introduction 1.1 Specifications 2.0 VGA Terminal Design 2.1 Counting pixels and lines 2.2 Generating the video 2.3 Video color 2.4 Video static RAM 2.5 Keyboard interface 2.6 Host serial port 3.0 Software Description 3.1 Settings 4.0 RDT64-1 Circuit Board Assembly 4.1 Preparation 4.2 Assembly checklist 4.3 Circuit board checkout 5.0 Customization Appendix A RDT64-1 Printed Circuit Board (PCB) Parts List Appendix B RDT64-1 System Parts List Appendix C RS-232 Serial Interface Connector Appendix D PS/2 Keyboard Connector Appendix E VGA Display Connector Appendix F References Appendix G Response to Control Characters from Host Appendix H Response to Escape Sequences from Host Appendix I Character EPROM Appendix J Default Font Appendix K Schematics Appendix L Circuit Board Image RDT64, Retro Dumb-Terminal 3 1.0 Introduction The RDT64 (Retro Dumb-Terminal) is just what the name implies. It is a classic text-only dumb-terminal. But thanks to modern components and programmable logic it packs a lot of functionality into a small package. It contains five programmable chips: two 8-bit PIC microcontrollers, two ATF16V8 generic array logic (GAL) chips, and an EPROM. Several of the ideas for the RDT64 came from the first computer I built, a digital group Z80 and its TVC-64 video card. 1.1 Specifications ! Power " +5 VDC at 300 mA " Coaxial 2.1 mm power jack, center positive ! Serial communications with Host " RS-232 levels " 8 data bits, no parity, 1 stop bit (8N1) " 9 pin, female, DCE connector " Baud rates: 1200, 2400, 4800, 9600. ! Keyboard " Standard PS/2 keyboard ! Display " Standard VGA display ! VGA signal " Modified VGA text mode - 64 characters per line, 25 lines, 1600 characters on screen RDT64, Retro Dumb-Terminal 4 2.0 VGA Terminal Design Anyone who has worked with computer displays knows there is not a single VGA (Video Graphics Array) display format. So called “standard VGA” has an active display area 640 pixels wide by 480 pixels high. DOS text mode VGA is 640 pixels wide by 400 pixels high; 80 characters by 25 lines. The RDT64 has an active area 512 pixels wide by 400 pixels high; 64 characters by 25 lines. The horizontal timing specifications for the Standard, Text mode and RDT64 VGA are shown in Table 2.1 and the accompanying diagram. Table 2.1 Horizontal Timing Specs VGA TYPES “Standard” “Text Mode” RDT64 Horizontal Pixels 640 640 512 Vertical Scan Lines 480 400 400 Horizontal Sync Polarity NEG NEG NEG Pixel Clock (MHZ) 25.175 25.175 20.0 † A = Scan line time (ìs) 31.77 31.77 32.0 B = Sync pulse length (ìs) 3.81 3.81 3.6 C = Back porch (ìs) 1.9 1.9 2.0 D = Active video time (ìs) 25.42 25.42 25.6 E = Front porch (ìs) 0.64 0.64 0.8 ______________________ ________ __________| VIDEO |________| VIDEO (next line) |-C-|----------D-----------|-E-| __ ______________________________ ___________ |___| |___| HSYNC |-B-| |-----------------A----------------| † The ideal clock frequency for the RDT64 is 20.14 MHZ but clock oscillators at that frequency are not available. However, 20 MHZ is only 0.7% below the ideal frequency and well within the synchronization range of VGA monitors. RDT64, Retro Dumb-Terminal 5 The vertical timing specifications for the Standard, Text mode and RDT64 VGA are shown in Table 2.2 and the accompanying diagram. Table 2.2 Vertical Timing Specs VGA TYPES “Standard” “Text Mode” RDT64 Horizontal Pixels 640 640 512 Vertical Scan Lines 480 400 400 Vertical Sync Polarity NEG POS POS Vertical Frequency (Hz) 59.9 70.0 69.6 O = Total frame time (ms) 16.68 14.27 14.37 P = Sync pulse length (ms) 0.06 0.06 0.064 Q = Back porch (ms) 1.05 1.11 1.12 R = Active video time (ms) 15.25 12.71 12.8 S = Front porch (ms) 0.32 0.38 0.384 ______________________ ________ __________| VIDEO |________| VIDEO (next frame) |-Q-|----------R-----------|-S-| __ ______________________________ ___________ |___| |___| VSYNC |-P-| |----------------O-----------------| 2.1 Counting pixels and lines VGA controllers are based on two counters; a horizontal or pixel counter, and a vertical or line counter. The horizontal counter (74HC4040, U11) counts the pixels in each line. Refer to Appendix K for the RDT64 schematics. Programmable logic (ATF16V8, U12) starts and ends the horizontal blanking signal (HBLANK) and the horizontal synchronization signal (HSYNC) at specific values of the pixel count. Figure 2.1 shows the structure of a VGA frame and the signals that define it. Both the horizontal and vertical blanking signals span three sub-parts: the Front Porch, the Sync, and the Back Porch. At the upper-left corner both counters equal zero. As the first scan line is sent to the VGA monitor the pixel counter increases. When the pixel counter equals 512 the HBLANK signal begins and the active (displayed) region of the line ends. When the pixel count equals 528 the HSYNC pulse begins - it ends when the pixel count equals 600. Finally, RDT64, Retro Dumb-Terminal 6 when the pixel count reaches 640, the pixel counter is reset to zero, and the line counter is incremented. Note that the HBLANK signal does not go to the VGA monitor, it is used to disable the video output of the RDT64. Figure 2.1 Diagram of VGA frame timing. In a similar fashion, the vertical counter (74HC4040, U6) counts the scan lines in each screen. Programmable logic (ATF16V8, U7) starts and ends the vertical blanking signal (VBLANK) and the vertical synchronization signal (VSYNC) at specific values of the line count. When the line counter equals 400 the VBLANK signal begins and the active (displayed) region of the frame ends. When the line count equals 412 the VSYNC pulse begins - it ends when the line count equals 414. Finally, the line counter is reset to zero, when the line count reaches 449. Note that the VBLANK signal does not go to the VGA monitor, it is used to disable the video output of the RDT64. The HBLANK and VBLANK signals are OR’ed together in U7 to produce the BLANK signal. BLANK is used to gate the Red, Green and Blue video signals to the VGA connector (J3). RDT64, Retro Dumb-Terminal 7 2.2 Generating the video The ASCII code for each of the 1600 characters on the screen are stored sequentially in the 6116 (2k x 8) SRAM chip (U5) and the pixel map for each of the 256 possible ASCII codes is stored in the 2764 (8k x 8) EPROM (U4). See Appendix I for details on the character EPROM. The character EPROM stores a 16 x 8 pixel character map for each ASCII code. Thus, each ASCII character occupies 16 addresses which are the 16 rows, or scan lines, in each character. Let’s look at what happens at the start of a new frame - where the pixel and line counters both equal zero. The eleven address inputs of the SRAM are controlled by the counters; pixel count bits 3 to 8 (PQ3-PQ8) connect to A0-A5 respectively. These six bits count the 64 (0-63) characters in each line. Line count bits 4 to 8 (LQ4-LQ8) connect to A6-A10 respectively. These 5 bits are the character lines; each character line is composed of 16 scan lines. So, for the start of the first line, SRAM A0-A10 are all zero and the SRAM will output the ASCII code for the first character. We’ll deal with how that ASCII code gets into the SRAM later. The 8-bit ASCII value from the SRAM connects to A4-A11 of the character EPROM. A0- A3 are connected to line count bits LQ0-LQ3 respectively. Essentially A4-A11 select the ASCII character and A0-A3 select the row (scan line) in that character’s map; 0000 is the top row and 1111 is the bottom. The eight bits in the selected character row appear at the EPROM output and are connected to the parallel data inputs of the 74HC165 parallel-to-serial shift register (U3). The data is loaded into the shift register by the parallel load (PLD\) signal from U12. PLD\ pulses on every eighth bit of the 20 MHZ clock while an inverted clock signal clocks the bits out of the serial shift register. These serialized bits are the PIXELS seen on the VGA monitor. At the end of the horizontal line, following the Back Porch, U12 pulses PQ_CLR which resets the pixel counter and increments the line counter. The process repeats but this time LQ0- LQ3 is 0001 so the character EPROM will output the second row in the character map.
Recommended publications
  • User's Manual L Tqmx80uc UM 0102 L © 2020, TQ-Systems Gmbh Page I
    User's Manual l TQMx80UC UM 0102 l © 2020, TQ-Systems GmbH Page i TQMx80UC User's Manual TQMx80UC UM 0102 2020-02-04 User's Manual l TQMx80UC UM 0102 l © 2020, TQ-Systems GmbH Page i TABLE OF CONTENTS 1. ABOUT THIS MANUAL......................................................................................................................................................................... 1 1.1 Copyright and License Expenses .................................................................................................................................................... 1 1.2 Registered Trademarks ...................................................................................................................................................................... 1 1.3 Disclaimer ............................................................................................................................................................................................... 1 1.4 Imprint ..................................................................................................................................................................................................... 1 1.5 Service and Support ............................................................................................................................................................................ 1 1.6 Tips on Safety .......................................................................................................................................................................................
    [Show full text]
  • 21APPN003 E1 Appnote 003 Application Note
    21APPN003 E1 - 2002-12-18 Using P1/P501 Graphics on MEN 824x/ALI boards under ELinOS Application Note Embedded Solutions Board-Level Computers for Industrial Applications ® About this Document About this Document This document describes how to configure P1/P501 graphics mezzanines under ELinOS 2.1 on MEN’s 824x/ALI series PowerPC boards (F1N, B11, A12, D3, SC13). When you have followed these instructions, you'll be able to: • use a VGA monitor as a Linux text console. • access the graphics memory from an application program through /dev/fb0. • run QT/embedded programs. • run X-Window system server (on a frame buffer basis). History Edition Description Technical Content Date of Issue E1 First edition Klaus Popp 2002-12-18 Conventions This sign marks important notes or warnings concerning proper functionality of the ! product described in this document. You should read them in any case. italics Folder, file and function names are printed in italics. bold Bold type is used for emphasis. monospace A monospaced font type is used for listings, C function descriptions or wherever appropriate. hyperlink Hyperlinks are printed in blue color. The globe will show you where hyperlinks lead directly to the Internet, so you can look for the latest information online. MEN Mikro Elektronik GmbH 2 21APPN003 E1 - 2002-12-18 About this Document Copyright Information MEN reserves the right to make changes without further notice to any products herein. MEN makes no warranty, representation or guarantee regarding the suitability of its products for any particular purpose, nor does MEN assume any liability arising out of the application or use of any product or circuit, and specifically disclaims any and all liability, including without limitation consequential or incidental damages.
    [Show full text]
  • Towards a Trustworthy Thin Terminal for Securing Enterprise Networks By
    Towards a Trustworthy Thin Terminal for Securing Enterprise Networks by Evan J. Frenn A Thesis Submitted to the Faculty of the WORCESTER POLYTECHNIC INSTITUTE in partial fulfillment of the requirements for the Degree of Master of Science in Computer Science May 2013 APPROVED: Dr. Craig A. Shue, Major Advisor Dr. Krishna K. Venkatasubramanian, Reader Dr. Craig E. Wills, Head of Department Abstract Organizations have many employees that lack the technical knowledge to securely operate their machines. These users may open malicious email attachments/links or install unverified software such as P2P programs. These actions introduce significant risk to an organizations network since they allow attackers to exploit the trust and access given to a client ma- chine. However, system administrators currently lack the control of client machines needed to prevent these security risks. A possible solution to address this issue lies in attestation. With respect to computer science, attestation is the ability of a machine to prove its current state. This capability can be used by client machines to remotely attest to their state, which can be used by other machines in the network when making trust decisions. Previous research in this area has focused on the use of a static root of trust (RoT), requiring the use of a chain of trust over the entire software stack. We would argue this approach is limited in feasibility, because it requires an understanding and evaluation of all the previous states of a machine. With the use of late launch, a dynamic root of trust introduced in the Trusted Platform Module (TPM) v1.2 specification, the required chain of trust is drastically shortened, minimizing the previous states of a machine that must be evaluated.
    [Show full text]
  • IBM VGA XGA Technical Refe
    Preliminary Draft May 19th 1992 Video Subsystem Preliminary Draft May 19th 1992 2 Preliminary Draft May 19th 1992 Video Subsystem Section 1. Introduction ....................... 1-1 Video Subsystem .......................... 1-2 Section 2. VGA Function ...................... 2-1 VGA Function Introduction ..................... 2-5 Major Components ......................... 2-7 Hardware Considerations ..................... 2-11 Modes of Operation ......................... 2-12 Video Memory Organization .................... 2-24 Registers ............................... 2-41 VGA Programming Considerations ................ 2-97 Video Digital-to-Analog Converter ............... 2-104 VGA Video Extensions ...................... 2-107 Section 3. XGA Function ...................... 3-1 XGA Function Introduction ..................... 3-7 VGA compatibility .......................... 3-16 132-Column Text Mode ....................... 3-16 Extended Graphics Mode ...................... 3-20 XGA Display Controller Registers ................. 3-34 Coprocessor Description ...................... 3-90 Coprocessor Registers ...................... 3-132 XGA System Interface ....................... 3-169 Virtual Memory Description ................... 3-177 | XGA Adapter Identification, Location and XGA Mode Setting 3-192 | VGA Modes ............................. 3-223 | Programming the XGA subsystem ............... 3-230 Section 4. Display Connector ................... 4-1 Display Connector Introduction .................. 4-2 Index .................................
    [Show full text]
  • Compile Your Own Linux Kernel Introduction
    LinuxFocus article number 252 http://linuxfocus.org by Philip de Groot Compile your own Linux kernel <philipg/at/authors.linuxfocus.org> About the author: I expect to receive my PhD from the Universiteit van Nijmegen during this year. My thesis is on what we call chemometrics. I'm presently working on computer technology applied to biology, at the Academic Medical Center in Amsterdam, the Netherlands. In addition I maintain my own page for Linux newbies Abstract: (in Dutch): it is one of the many initiatives by and for You will presently find out that you too can get, configure, compile, the linux community. I love and install your very own kernel. working with Linux and I frequently report on my experiences. _________________ _________________ _________________ Translated to English by: Nino R. Pereira <pereira/at/speakeasy.org> Introduction Why would you even want to compile and install a new kernel all your own? Possible reasons are: The new kernel has better hardware support. The new kernel offers certain advantages, such as better support for multiple-processor machines (SMP), or support for the USB. This applies to the 2.4.x kernels. The new kernel lacks old bugs. Your own kernel lacks superfluous elements and is therefore faster and more stable. It is a problem that compiling ("rolling") your own kernel demands a fair amount of computer savvy. Therefore a new Linux user will not attempt to get into compiling kernels lightly. This article shows screen dumps of the way to do compile the kernel using the command 'make xconfig'. With this command the user handles the kernel through a GUI, a Graphical User Interface, and the mouse.
    [Show full text]
  • Masters Thesis, Toomas Soome 2018
    UNIVERSITY OF TARTU Institute of Computer Science Computer Science Curriculum Toomas Soome Porting and Developing a Boot Loader Master’s Thesis (30 ECTS) Supervisor(s): Meelis Roos Tartu 2018 Porting and Developing a Boot Loader Abstract: This paper describes the project to replace outdated boot program in illumos project with alternative one, allowing to provide better support for modern and future computer systems and having an architecture to support extending and improving the implementation. Keywords: Boot Loader, Operating System, FreeBSD, illumos CERCS: P175 Informatics, systems theory Boot programmi portimine ja arendamine Lühikokkuvõte: See magistritöö kirjeldab projekti, mille eesmärk oli asendada illumos projektis aegunud boot programm alternatiivsega, mis võimaldab paremini toetada kaasaegseid ja tuleviku süsteeme ning mille arhitektuur võimaldab parenduste ja täienduste kirjutamist. Võtmesõnad: Boot Loader, Operating System, FreeBSD, illumos CERCS: P175 Informaatika, süsteemiteooria 2 Table of Contents 1 Introduction .............................................................................................................. 5 1.1 What is this all about ......................................................................................... 5 2 Boot Loader .............................................................................................................. 6 2.1 Boot Loader Components.................................................................................. 6 Access to the Storage ...............................................................................................
    [Show full text]
  • CHIPS 69000 Data Book
    69000 69000 HiQVideo Accelerator with Integrated Memory Data Sheet Revision 1.3 August 1998 PRELIMINARY Copyright Notice Copyright 1997-98 Chips and Technologies, Inc., a subsidiary of Intel Corporation. ALL RIGHTS RESERVED. This manual is copyrighted by Chips and Technologies, Inc., a subsidiary of Intel Corporation. You may not reproduce, transmit, transcribe, store in a retrieval system, or translate into any language or computer language, in any form or by any means - elec- tronic, mechanical, magnetic, optical, chemical, manual, or otherwise - any part of this publication without the express written permission of Chips and Technologies, Inc., a subsidiary of Intel Corporation. Restricted Rights Legend Use, duplication, or disclosure by the Government is subject to restrictions set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at 252.277-7013. Trademark Acknowledgment CHIPS Logo is a registered trademark of Chips and Technologies, Inc., a subsidiary of Intel Corporation. HiQVideo, is a trademark of Chips and Technologies, Inc., a subsidiary of Intel Corporation. All other trademarks are the property of their respective holders. Disclaimer This document provides general information for the customer. Chips and Technologies, Inc., a subsidiary of Intel Corporation, reserves the right to modify the information contained herein as necessary and the customer should ensure that it has the most recent revision of the document. CHIPS makes no warranty for the use of its products and bears no responsibility for any errors which may appear in this document. The customer should be on notice that many different parties hold patents on products, components, and processes within the personal computer industry.
    [Show full text]
  • Building Coreboot for Protectli Platforms
    Building coreboot for Protectli platforms Step-by-step guide 3MDEB CONTACT ul. Burgaska 9D/10 Piotr Król, 3mdeb CEO 80-287 Gdańsk, Poland +48 880 673 344 TAX ID: PL2530164147 [email protected] Website About Us Introduction This document describes how to build a coreboot image for Protectli platforms using the upstream coreboot repository. Although coreboot is an open-source firmware framework, building firmware for x86 architecture is currently impossible without certain blobs. These blobs consists of: CPU microcode (automatically included during build process) Intel Firmware Support Package - silicon initialization code in binary form require to initialize modern Intel CPU. May be automatically included in coreboot image or an explicitly selected blob file. VGA option ROM - a binary required for BIOS graphics output to display logo or boot menu Preparing environment In order to build coreboot image a Linux operating system is preferred. Additionally a docker container will be used in the build process to ensure all the libraries and utilities have correct versions, the appropriate toolchain is present and the build will proceed without errors. Install Docker for the Linux distribution you are using. You may refer to https://docs.docker.com/engine/install/ for installation process. The build process is also possible on Windows 10 machine. However it requires Pro version to have correct Docker support and it has not been thoroughly validated. If you are experienced enough, you may try Windows. Install git: sudo apt-get install git # or sudo yum install git # or sudo dnf install git . Clone the coreboot repository with its submodules: git clone --recurse-submodules https://review.coreboot.org/coreboot.git .
    [Show full text]
  • User-Space Debugging Simplifies Driver Development
    QNX Software Systems Ltd. 175 Terence Matthews Crescent Ottawa, Ontario, Canada, K2M 1W8 Voice: 1 800 676-0566 +1 613 591-0931 Email: [email protected] Web: www.qnx.com User-Space Debugging Simplifies Driver Development Chris McKillop QNX Software Systems Ltd. [email protected] Introduction The traditional approach to driver development, in which every driver is written and debugged as part of the OS kernel, can seriously hamper the progress of an embedded project. For instance, a single programming error in any kernel-space driver can crash the target system. As a result, driver developers often waste time rebuilding and rebooting the target instead of actually testing and debugging software. To complicate matters, most embedded systems lack the non-volatile storage needed to save a kernel core dump between reboots. This makes post- mortem debugging which would help locate the source of the system failure nearly impossible. As a further problem, kernel debuggers typically halt the entire system while the developer inspects the code or data of the driver being debugged. Because everything must run in lockstep with the debugger, the developer can easily miss bugs that would occur in a live system, where events happen asynchronously. Debugging Drivers in User Space Page 1 Fortunately, not all OSs rely on in-kernel drivers. The QNX® Neutrino® microkernel OS, for instance, treats every driver as a standard, user-space application. So, if any driver fails, the OS can cleanly terminate the driver and reclaim all the resources it was using; there’s no need to rebuild and reboot. Better yet, drivers can be debugged with the same, standard process-level debuggers used to debug regular applications.
    [Show full text]
  • VGA Function Specification Gxm/Mxi Processors
    VGA Function Specification GXm/MXi Processors January 16, 1998 - Rev. 0.1 Cyrix Corporation Confidential ©1998 Copyright Cyrix Corporation. All rights reserved. Printed in the United States of America Cyrix is a registered trademark of Cyrix Corporation. Cyrix Trademarks include: Cx5520, Cx5530, Display Compression Technology (DCT), MediaGX, XpressAUDIO, XpressGRAPHICS, XpressRAM, Virtual System Architecture (VSA) All other products mentioned herein are trademarks of their respective owners and are hereby recognized as such. Cyrix is a wholly-owned subsidiary of National Semiconductor® Corp. Cyrix Corporation 2703 North Central Expressway Richardson, Texas 75080 United States of America Cyrix Corporation (Cyrix) reserves the right to make changes in the devices or specification described herein without notice. Before design-in or order placement, customers are advised to verify that the information on which orders or design activities are based is current. Cyrix warrants its products to conform to current specifications in accordance with Cyrix’ standard warranty. Testing is performed to the extent necessary as determined by Cyrix to support this warranty. Unless explicitly specified by customer order requirements, and agreed to in writing by Cyrix, not all device characteristics are necessarily tested. Cyrix assumes no liability, unless specifically agreed to in writing, for customer’s product design or infringement of patents or copyrights of third parties arising from use of Cyrix devices. No license, either express or implied, to Cyrix patents, copyrights, or other intellectual property rights pertaining to any machine or combination of Cyrix devices is hereby granted. Cyrix products are not intended for use in any medical, life saving, or life sustaining systems.
    [Show full text]
  • P Relim~Inary
    ••••••••••••• ••••• ••••••••••••••• ••••• • •••• ~ni~~ ______________p_relim~inary 82C456/460 ENHANCED FLAT PANEL/CRT VGA CONTROLLER DATABOOK February 1990 Revision 0.03 STK# 10456-001 c .:::::= :=:~ ::::: •• ::::: \.t;ir-:, _____________________________ P_R_EL_IM_IN_A__ RY 82C456/460 ENHANCED FLAT PANEL / CRT VGA CONTROLLER • 100% IBM VGA-compatible II Text enhancement feature improves contrast on flat panel displays • Supports analog and digital CRT monitors and LCD, plasma, and electroluminescent II Programmable vertical compensation panels techniques increase usable display area • Up to 64 gray levels on monochrome &I IBM VGA monochrome CRT compatibility panels on monochrome panels • RGB color to grayscale reduction II Advanced SLEEP mode minimizes power techniques consumption • Drives color panels with 64 colors til Proven DOS and OS/2TM compatibility II SMARTMApTM intelligent color to grayscale • Full backwards compatibility with IBM conversion EGA, CGA, MDA and Hercules graphics standards ... 82C460 ~ Address Address I--- -----+ Buffer ~ Palette ..... -"'- DAC To CRT Data u Data .... -~ Xcvr .. Sync ........ r- 82C456 Driver BIOS '-- ~ ROM -- -----+ To Flat Video .. ... Panel .. Driver .. Control ... : Video Memory 82C456 SYSTEM BLOCK DIAGRAM STK # 10456-001 Printed in U.S.A 2190 Rev 0.03 •••••• •••• ••••• •••• ....... .. .:~: ...........• . '-" i r-:- ________________T_ab_le_o_f C_o_nt_e_nts Table of Contents ~S~e~ct~io~n~ ________________________ ~ Sect jon Eag.e, 82C456 Introduction........................................ 3 Programming
    [Show full text]
  • Is There a New Loader in Freebsd 13.0? by TOOMAS SOOME
    1 of 4 Is There a New Loader in FreeBSD 13.0? BY TOOMAS SOOME The short answer is “no, it is still the same good old loader.” But we are trying to make it more friendly and support more features. I started working with boot loaders that were not on FreeBSD but on illumos. At that time, illumos was using old grub 0.96 and supported only the BIOS boot. UEFI systems were already around at that time and illumos really needed to support UEFI systems. My initial work was to investigate newer grub. It was feature-rich, widely used but hard to manage, and its licensing is not friendly when you need to support features specific to file systems like zfs or to add operat- ing-system specific features. This led me to the FreeBSD boot loader and contributing to its de- velopment. When I started porting the FreeBSD boot loader to illumos, illumos supported a serial con- sole and VGA text mode console only. To support UEFI, I had to implement support for the UEFI framebuffer-based console for the illumos kernel. Once implemented, a logical step was to add the same feature for the loader, and when there is an option to draw the console on the UEFI framebuffer, then re-using the same code to draw on the Vesa BIOS Extensions (VBE) lin- ear framebuffer is just another logical step in development. Once done, we got public postings like this https://omnios.org/setup/fb: Figure 1 Loader with ascii art. FreeBSD Journal • March/April 2020 17 2 of 4 Figure 2 Loader with images.
    [Show full text]