8-Bit Portable Internet-Enabled Computer

A portable computer based on the MOS 6502 that aims to enhance security and privacy.

Similar projects worth following
HTTP, non-free javascript, and the Intel Spectre and Meltdown vulnerabilities make modern computers far too insecure to use for modern applications.

Why not turn to an 8-bit CPU that can't run javascript, and doesn't have speculative execution, in order to make sure YOU can't get hacked!

Technology moves fast in today’s world, but this is not necessarily a good thing. The reliance we have on the World Wide Web and Intel CPUs is advertised by the biggest corporate marketing departments as nothing but a good thing. The fact that the biggest parts of our computer hardware, computer software, and internet functionality is provided by monopolies is glossed over, if it is mentioned at all.

Here I want to address the 2018 Hackaday Prize submission criteria of “Building Hope”, and why my competition entry does build hope. The category of the competition I am entering is Open Hardware, and I want to show how my open hardware design builds hope.

My open hardware entry is an internet-enabled 8-bit portable computer. I am aiming for my design to be as low cost as possible, and I want it to avoid many of the devastating problems I can see with most contemporary internet-enabled portable devices. The two main problems I want my 8-bit computer to address are (a) the devastating privacy and security problems of HTTP (the World Wide Web) as the main platform for internet connectivity; and (b) the devastating security problems of modern Intel CPUs, which can be found in the vast majority of internet-connected consumer devices today.

HTTP: Bad for Privacy, Because of Bad Politics

The internet is now loaded with non-free javascript. A great many websites secretly and silently load lots of programs onto your computer, and this is an invasion of privacy. In some cases the programs non-free javascript load onto your computer are malware.

The same sort of principle behind non-free javascript invading your privacy and compromising your security applies to the way Graphical User Interfaces on modern devices work. The way users interface with their mobile phones and tablets is anything but transparent. Phones and computers are now supposed to be nothing but a collection of “apps”. Today’s mobile phones are easy to use, but it is impossible to tell exactly what your device is actually doing with the data you are giving it. You can’t access logs, you can’t start and stop services and daemons yourself, and you can’t manage memory in the same way you can, say, from a Command Line Interface.

Many modern devices are designed just to go on the web. We call low end lean terminals with operating systems based on Chrome “netbooks”. This is a terrible way to use computers, and a terrible way to use the internet. HTTP is an inefficient and insecure method of information distribution. The shift to using cloud computing in order to be productive and useful presents a scary prospect for information safety and privacy.

In some contexts, the entire user interface of a user’s computer is HTTP, loaded with javascript. The web is frequently used exclusively for being productive, being social, or being entertained. The problems with computer Graphic User Interfaces carry directly over to web productivity, with the added security vulnerabilities of cookies and non-free javascript. The metadata fingerprints we are leaving behind while doing our work on web interfaces is like a barrel of radioactive waste, spewing out traces of radiation everywhere.

This article ( by Simon E Spero shows that HTTP is a slow and inefficient internet protocol. Most of the time, HTTP is waiting. The slow start to HTTP connections hurts performance, and slows down the Round Trip Time (RTT). HTTP is also a highly centralised protocol. This means that all HTTP data is stored in a centralised server, and all clients must negotiate with the central server 100% of the time in order to establish connections and distribute data.

USENET is entirely different. NNTP is a much more horizontal method of information distribution. Servers synchronise messages and data with other servers, and this means that users can connect to their local server in order to access data. NNTP spreads...

Read more »


First few hours of work on a conceptual flowchart of the architecture of the 8 bit laptop.

Portable Network Graphics (PNG) - 83.23 kB - 04/07/2018 at 07:17



Andre Fachat's Diagrams for using the 74LS610 as a paged MMU.

Graphics Interchange Format - 8.07 kB - 04/07/2018 at 07:17



Andre Fachat's Diagrams for using the 74LS610 as a paged MMU.

Graphics Interchange Format - 14.73 kB - 04/07/2018 at 07:17


svg+xml - 26.80 kB - 04/07/2018 at 07:17


The source code for operating the HobbyTronics Serial-to-VGA monitor board. Obtained from:

Zip Archive - 614.20 kB - 03/22/2018 at 03:54


View all 6 files

  • 1 × 6502B The CPU at the heart of the portable computer
  • 1 × P8X32A Parallax Propeller For processing the 100 column x 50 row text display
  • 1 × 24LC512 Serial EEPROM Use for controlling the Parallax Propellor Video display
  • 1 × HobbyTronics Serial to VGA Board, Self-Constructed
  • 1 × 74LS612 4-line to 12-line address expander, used as a Memory Controller, to expand the memory of the computer

  • Settling On Video

    Blair Vidakovich3 days ago 0 comments

    This project seems to fit the bill quite well regarding video display:

    I think I will use this component for my computer's video (:

  • New Life.

    Blair Vidakovich3 days ago 0 comments

    It has been many years since I have been here!

    I am going to be breathing new life into this project (:

  • Using the Atari TIA (Television Interface Adaptor)

    Blair Vidakovich02/07/2019 at 11:48 0 comments

    This is just a quick blog post to say that I have revised my plan for this project a little.

    I have decided to make the computer use 32K or 48K of RAM.

    I have found a cheaper 4G cell breakout board than the one that I originally specified.

    I have also decided not to go with the Hobbytronics open source serial-to-VGA video driver, and instead use the TIA from the Atari 2600 as the video chip for the computer.

    The following is the implementation of the TIA in the Atari 2600, which uses the TIA to generate a composite output, which is then combined into an RF signal.

    And I will draw up schematics showing how I will change this circuit to display composite video and monoaural audio.

    The TIA is a very versatile device which is capable of 128 colours in NTSC video, with one colour per scanline. With special coding, it is possible to draw up to 36 columns of text.

    See THIS[1] forum post and THIS[2] blog post for more details.

    This is an example of the text display. This is 36 columns. I think it is possible to go further.

    And another example of text display on the TIA. This is 24 columns:

    Both the TIA and VIC chips are available for cheap online as new parts, and also in broken machines, so I think this is a good idea.

    I may experiment with the VIC from the VIC-20, to see which chip I like best.

    The TIA is also capable of fantastic 8-bit graphics.

  • Ideas for Handling Interrupts

    Blair Vidakovich04/12/2018 at 10:23 0 comments

    Check out this project's thoughts on handling interrupts:

  • Another Previous 6502 Project!

    Blair Vidakovich04/12/2018 at 10:13 0 comments

    Just discovered this projec here: (!

  • Cellular Data

    Blair Vidakovich04/12/2018 at 07:47 0 comments

    This ( website lead me to the ublox SARA modules.

    I think I'll be using a celluar data module like this one ( in my design. I think it will necessitate another ACIA serial chip.

    As far as I can tell, the ublox chips can interface via UART, and recieve AT commands. There are modules that do LTE and positioning as well.

  • Moving From the Exotic 74LS610 MMU to Normal Bank Switching

    Blair Vidakovich04/12/2018 at 05:12 3 comments

    I have been trying to wrap my head around exactly how the 74LS610 Memory Management Chip will work in my Hackaday Prize competition entry. There is not a lot of complete documentation on exactly how to implement the 74LS610. So, ultimately, I decided to scrap using the chip, and I decided to use a simpler and more rough-and-ready solution to how to extend the memory of this internet-enabled 8 bit laptop I am building.

    I did some searching, and I found a solution I can actually understand:

    This document outlines how to extend the ROM of a computer to 128K bytes, and the RAM to 512K bytes. This is the schematic:

    The incredible benefit of this solution is that it minimises the amount of programming needed in order to switch banks of ROM and RAM.

    Selecting Between the ROM and RAM

    The implementation uses one half of a 74HCT139 decoder to select between the ROM and RAM. When A15 is high, RAM is selected; when A15 is low, ROM is selected. A15 is gated with /MREQ to assure that the memory chips are enabled only when the bus access is for memory, and only when the address lines are stable.

    The Bank Switch Latch

    As the document outlines, a 74HCT273 eight-bit latch serves as the bank switch latch. Because this circuit is intended for a Z80 processor, the circuit requires the user to output bank switch information with a Z80 OUT instruction, which would generate the output strobe /BANK. Because we are using a 6502, I imagine we could do that with the VIA.

    The document specifies that a 74HCT138 or similar part (not shown in this schematic) would interface with the Z80 processor to recieve an OUT opcode to generate the bank switch strobe and other needed I/O strobes. At power-on, the /RESET signal resets all the bank switches to zero.

    The Eight AND Gates

    The latched bank switch output signals, BS0 through BS7, are connected to one input of each of eight 74HCT08 AND gates. The outputs of these gates are used to generate extra address lines for the ROM and RAM chips—three for the ROM, and five for the RAM.

    Using A14 to Gate the Bank Switching

    Each of the eight 74HCT08 AND gates has its other input tied to Z80 address line A14. When A14 is high, the extra address lines will follow the values latched in the 74HCT273 bank switch latch. When A14 is low, the extra address lines will all be set low, regardless of the values latched in the bank switch latch. However the last values stored in the bank switch latch remain there, ready for the next access
    to a bank-switched memory area.

    Very Simple!

    As you can see, this is a very simple solution to what could be a complex problem. Using the VIA chip already being used in this design, and just by using A14 and A15 of the 6502, we are able to increase our total ROM addressable to 128K bytes, and RAM to 512K bytes. I think this will be sufficient.

    The Memory Map

    The document we are working with specifies this as the memory map of the design:

    There are four areas in the memory map. The power of this design is that there are 16K bytes each of ROM and RAM which are base ROM and RAM. This means that these areas are not switched out upon switching banks, which means permament program information can be stored in these banks, which is very useful. I imagine we can section of parts of these 16K byte areas for IO. The stack can be located in the base RAM area, and the reset vectors needed for the 6502 can be located in the base ROM area.

    A Bank Switch Shadow

    There will need to be an area in the base RAM area which shadows the state of the bank switch latch. This is so the operating system of the computer can keep track of the state of the bank switch latch. This will be useful for multi-tasking applications.

  • Perhaps aim for 32KB or 48KB RAM.

    Blair Vidakovich04/10/2018 at 11:49 0 comments

    I wanted to write quite a nice operating system for the new computer, so I thought about a megabyte of RAM would be useful, and make the task easier - but wrangling the MMU gives me some grief.

    Perhaps it would be easier to just stick within the 2^16 memory space? Like 48KB or 32KB RAM.

    I'll do some more research on virtual memory spaces for 16 bit memory spaces.

  • Second Effort at Constructing Architecture

    Blair Vidakovich04/08/2018 at 10:08 0 comments

    ROM and IO (through the 6522 VIA) is not that difficult.

    I need to find something to decode the address logic though - but that shouldn't be too difficult.

    I pirated this academic article - check out some of the diagrams from it. If you'd like a copy of the article I'd be more than happy to provide it.

  • Beginning of Architecture Construction

    Blair Vidakovich04/07/2018 at 07:04 5 comments

    Here's my firs couple of hours making a simple conceptual flowchart for the architecture of the 8-Bit Portable Computer.

    I don't have the protection circuitry for the 74LS612 MMU finished, so I didn't want to go into a complete electrical schematic.

    The things missing in this diagram are:

    • Memory-mapped ROM
    • Memory-mapped IO

    I anticipate that I may need a second 6522 ACIA in order to debug the system.

    At the moment, most of the components for the computer are remaining very cheap, so I am hoping this may be able to be copied and built elsewhere.

View all 10 project logs

Enjoy this project?



Dylan Brophy wrote 03/29/2018 at 01:06 point

We need this project.  I am very interrested to see how this turns out.  Best of luck, good sir!

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates