Category: Project

An Update on the Neutron

So. Remember that old project I made like one or two posts about? The Neutron retro microcomputer? Yeah, it’s not exactly a microcomputer anymore. I have changed my end goal. Now I want to make a 16-bit game console, something similar to a Super Nintendo or a Sega Genesis, but not compatible with either. What does this mean?

  • The Neutron will still be using a W65C816S microprocessor, now with a target clock frequency of 8 MHz instead of the full 14 MHz.
  • There will be one FPGA to handle both audio and video output.
  • There will be one chip, either an FPGA or CPLD, to handle de-multiplexing the processor’s address and data lines (because Western Design Center thought making the data bus act as the most significant byte of the address bus sometimes was a good idea, even though it really isn’t and just complicates things).
  • System RAM and Video RAM will be separated. Amounts are currently unknown.
  • There will be at least one slot for an SD card, so you don’t have to deal with battery-backed Save RAM in the cartridges.
  • There will be 4 controller ports. It is currently unknown what the controller ports will be, or what inputs the controllers will have.
  • There will need to be a cartridge slot mapped to one half of the memory map (8 MB).
  • Half of cartridge space (4 MB) will be banked using the same method (or a similar method) as used in the 8-Bit Guy’s Commander X16 project, for a total of 4 MB * 256 Banks = 1 GB in that one area. The other 4 MB area is static.
  • There will be a parallel expansion port, because who knows what people will want to make.
  • Audio/Video output is indeterminate at this stage. I’m hoping for something capable of both digital and analog output. Perhaps something based on DVI-I Single Link, which would be capable of both VGA and HDMI compatible video out, as well as some pins for analog audio out and (maybe) composite out.

Open Graphics

So today I was thinking about the RISC-V architecture and how it is awesome that an open CPU instruction architecture exists that anyone can implement in FPGA or custom silicon (assuming you can afford to), and then I thought about something – if people have made an open CPU architecture, why not an open GPU architecture to go along with it? Think about it. If you’re making a system-on-a-chip that uses an open processor ISA, wouldn’t it make sense to pair it with an open graphics architecture instead of having to sign some contract to implement someone’s intellectual property just to get graphics?

Luckily, it seems I’m not the first person to think about this – there is something called the Open Graphics Project which aimed to create an open architecture standard for graphics card. Sadly, it seems that project has been defunct for a few years at least, as their website is non-functional as of writing this, and the Wayback Machine’s latest working snapshot appears to be from 2015. Which makes me kind of sad because I think it is a good idea, and I would not be able to do it myself (I think I have made it clear multiple times that when it comes to hardware, I don’t really know what I am doing).

Well, I guess those are my two cents. If anyone has any comments, there’s a comments section. If that’s not enough, there’s a contact form on the about me page. You have an awesome day!


DAM: Decentralized Application Marketplace

Network Architecture DiagramHello! This is an idea I had that I don’t think anyone else has thought of yet, considering I can’t find anything similar through a DuckDuckGo search. Simply put, why not decentralize the app store?

Taking inspiration from how the Matrix protocol works, there are three types of nodes: Clients, who want applications, Merchants, who have applications, and Markets, which facilitate the entire process. In comparison to Matrix, a Merchant is equivalent to a homeserver, and a Market is equivalent to an identity server, but with more responsibilities. I don’t think I need to explain what a client is equivalent to (hint: its the same thing).

How the actual protocol works on a technical level is still up for debate, but only two pieces of software would be absolutely necessary: the Merchant server software and the Market server software. The Market software would handle accounts for Clients, as well as payments. There would probably be options for revenue share – either no share (dev gets all the profit from their app), share what you want (dev chooses how much they want to share with Markets), or fixed share (Market sets their take, limited to 50% and under) – since server hosting is not exactly free. The Merchant software would allow for developers to host applications, as well as multiple versions of the same application (i.e. Linux packages, Mac binaries, Windows binaries, Android APKs / x86 binaries, ARM binaries, RISC-V binaries). For share-what-you-want Markets, the dev chooses how much to share through the Merchant software. There could (and probably will be) client software as well, but it would be possible for the Market to have a web interface (through HTTPS) for Clients to use if they don’t want to use client software.

While this does at least appear to be a complicated system, it has one great benefit: you only need to have one account on one Market and you can access any application on any Merchant, and platform holders don’t need to host all the infrastructure necessary to support a large app store – they just need to host a Market server, add a compatible Client app to their platform, and any developer with compatible binaries on their Merchant server is now on your platform. Easy. Of course, it does mean offloading some of this infrastructure to the developers, but better to spread the burden around and make it easier for everyone than to put everything on one person or group.

That is all I can really say at the moment, as the idea is not fully developed, but I think this could be “very, very, interesting”. But what do you think? There should be comments under this post, but if you wish, I have a contact form on my about page which allows you to email me.

(Oh, and of course the protocol would be open source. Why wouldn’t it be? Just need to decide on a license – MIT, GPL, or something else?)


53 20 65 20 72 20 69 20 61 20 6c 0d 0a 43 20 6f 20 6d 20 6d 20 75 20 6e 20 69 20 63 20 61 20 74 20 69 20 6f 20 6e

If you decoded the title (and if you really did that instead of reading the permalink, you’re awesome), you’ll know what this post is about, at least generally. (Also, I was going to do binary, but I figured that would be too long).

Throughout computer history, we always needed a way to connect peripherals and stuff to our computers so we can do more stuff. Want to store your data? Connect up a cassette player, floppy drive, optical drive, (floptical drive??), or memory card reader. Want to print out that essay you just wrote? Connect a printer. You get the point, right? The thing is, there are many ways to connect things together.

Generally, there are two approaches towards connecting things to your computer: parallel (sending multiple bits at a time) and serial (sending one bit at a time). Then there are many different capabilities you can add onto that, such as daisy-chaining (think FireWire, or IEC/CBM bus; you connect one thing to your computer, then you connect something else to that thing and both can talk to the computer), multi-master (multiple computers on one bus), multi-slave (multiple peripherals on one bus), plug and play (you can rip the cable out of your computer and it won’t explode), etc.

For the Neutron, I think a daisy-chaining, multi-master, multi-slave serial connection would be useful, as such a connection could be used for multiplayer games and for sharing multiple peripherals between computers. The IEC bus almost fits our needs, with the only problem being that it does not support multiple computers on the same bus. I2C is also close, but still no cigar as it does not support daisy-chaining. So, we’ll have to modify one of them and/or combine them in some way. How to do that is beyond me at the moment.


Up down up down up down

I was watching Retro Game Mechanics Explained. It was a video about the Game Genie and how it’s codes worked. It was interesting.

I have a project I’ve been working on, at least in concept. It’s a computer based around the 65816 processor (I’m calling the computer the Neutron), and one of the things it will have is a cartridge port. These cartridges can be up to half a megabyte large without the need for banking hardware. So, I was thinking about how a Game Genie-like device could work for that project.

The 8-letter code entered (yes it had to be 8) would encode 1) a 24-bit address and 2) an 8 bit value. For the 24-bit address, the first 8 bits would tell which 64K bank was going to be accessed. Cartridge space runs from bank F4 to bank FB, so the first two letters would have to encode the hex digits F and 4-B.

As for the letters? It’s kind of simple. Here’s what I came up with:

  • A = 0000
  • Z = 0001
  • B = 0010
  • Y = 0011
  • C = 0100
  • X = 0101
  • D = 0110
  • W = 0111
  • E = 1000
  • V = 1001
  • F = 1010
  • U = 1011
  • G = 1100
  • T = 1101
  • H = 1110
  • S = 1111

Basically, the even numbers are assigned to A through H, while the odd numbers are assigned to Z through S. Simple!

Now for how those letters (and their assigned bits) are mapped to the address and value. For each set of 4 bits, we’ll say the first two will be represented by uppercase letters and the last two will be represented by lowercase letters. The 8 letters will be labeled A through H.

To map each letter’s bits to the address and value, take each pair of letters, say A and B, with bits AAaa and BBbb. The upper case bits (AA and BB) are unchanged. If the mapped address and value are below the bits for the letters, we’ll say that AA and BB go straight down. For the lower case bits, swap the pairs. You’ll end up with AAbb and BBaa. Do this for all other pairs of letters, with the addition that with every other pair of letters, invert the lowercase bits. (I.e CCcc and DDdd become CCdd and DDcc, with italics indicating an inverse bit). Then, take the pairs of sets of four bits (called nibbles), and going from the outside in, swap the first nibbles. So, if you start out with the bits AAaa BBbb CCcc DDdd EEee FFff GGgg HHhh, you will end with the bits GGhh BBaa EEff DDcc CCdd¬†FFee AAbb HHgg. Using those bits, the first six nibbles make up the 24-bit memory address and the final two nibbles make up the 8-bit value that should be returned when that address is accessed.