Blog Posts What am I doing?

Game Market Research, Take 2


Making a new post for the first time in forever, because I’m doing another survey. The previous survey was good, but times have changed and I’ve changed as well. You probably have too. So, let’s get this started.

Here’s a link if you prefer:

QR Code


Neutron PC32 Bill of Materials (for prototype at least)

  • Western Design Center W65C02S6TPG-14 Microprocessor
  • Clock Crystal/Oscillator – 8 MHz Maximum (poss. frequency divider for prototype?)
  • Alliance Memory AS6C62256A-70PCN (warn: EOL, all other THT 70ns 32kB/256kb SRAM are 10x price)
  • Microchip Technology/Atmel AT28C64B-15PU
  • Microchip Technology/Atmel AT27C010-70PU
  • 2 Western Design Center W65C22S6TPG-14 Versatile Interface Adapters
  • Western Design Center W65C51N6TPG-14 Asynchronous Communication Interface Adapter
  • Microchip Technology/Atmel ATMEGA4809-PF
  • Newhaven Display NHD-240128WG-ATFH-VZ#
  • Analog Devices DAC08CPZ
  • Some form of speaker (hooked up to DAC08CPZ)
  • All logic chips required for:
  • All logic chips required for address decode logic (mainly 4-to-16 and 3-to-8 multiplexers/demultiplexers/whatevers + inverters and other gates)
  • Some power supply (planned for finished device: 9V battery or DC power jack, both options present)
  • Connectors: DB25, 8-pin Mini-DIN, 6-pin DIN, some card edge connector, a DC output barrel jack for serial devices

WordPress unborked itself

Self-Explanatory. I can now access my website from my laptop again. Granted, the site is probably going to go down for a few minutes after I post this (because WordPress is WordPress) but whatever.


Finally blogging again.

It’s been a while. WordPress somehow broke itself such that I can’t access it on my laptop, but can still access it anywhere else. I really need to learn web design stuff so I can replace WordPress. Soon.

Anyways, I should probably update you on what’s going on. First, goats. Mainly because they’re shouting in the backyard as I type this out.

Second, I’ve made more changes to Neutron (and created a sister project codenamed Cellia). I’ll save those for a later date (as in, when I get wiki edit access and forum posting access on the RetroBrew Computers website).

Third, I still suck at Calculus and would like to skip to Linear Algebra cause I can understand it better (thanks to 3blue1brown for existing and making math youtube videos).

Fourth, I want to try and Ludum Dare.

Fifth, Bananas.

aight, bye.


Another Neutron Update + A Rant on Annoying 16-bit Microprocessor Things

Let us start off with the rant mentioned in the title. Whenever I think about making a retro computer or device of some sort, I immediately jump to 16-bit because that era is the most interesting one to me. Sadly, the 16-bit processors available on the market (or at least Mouser) are extremely annoying to design around.

Let’s start with the W65C816S, which was originally planned to be used in the Neutron. Annoying thing number #1: multiplexed pins. The 65816 has a 24-bit address bus and an 8-bit data bus, with a 16-bit internal architecture. However, the physical package only has 16 address pins. Where do the other 8 pins go? Why, they’re the data bits! Because for some god dang reason, Western Design Center decided that making the data bus sometimes be part of the address bus was a good idea (IT ISN’T). And that’s not taking into account annoying thing number #2: the interrupt vectors and handlers HAVE to be located in bank $00 (specifically, the vectors must be in the $00FF00 area). The stack is also restricted to bank $00. And this causes a dilemma: unless you’re willing to add a chip (or a feature to an existing chip) that copies the interrupt vectors and handlers from ROM into RAM on reset, you’re going to end up with a crazy memory map like the one in the Super Nintendo if you want to have a stack. So, TL;DR: The 65816 is annoying due to multiplexed address/data pins and the location the interrupt vectors and handlers have to be in.

Up next on the chopping block: The Z8000, or specifically the Z16C02 (being the only version that’s still on the market). For some reason, instead of just having SOME of the data pins act as address pins, THE ENTIRE ADDRESS BUS AND DATA BUS USE THE SAME GOD DANG PINS, WHAT WERE YOU THINKING ZILOG????? WHY DID YOU THINK THAT WAS A GOOD IDEA? AND WHY IS THE ONLY VERSION THAT’S STILL AVAILABLE THE ONE THAT CAN ONLY ACCESS 64K????

Finally we have the Motorola 68000. While Motorola isn’t producing it anymore, the semiconductor company that they spun off during the split, Freescale, does. Or should I say, DID, because NXP ate them. Luckily, NXP does make the chips available. Sadly, they’ve got too many variations. It is seriously confusing. I’d give you an image to demonstrate this, but WordPress is an unstable mess and I fear that trying to add an image will brick the site for another 5 minutes…

Okay… finally got that out of my system. Since there aren’t any easy-to-implement 16-bit processors on the market, I’m just going to start out with an 8-bit processor. The 6502 should do nicely. I do plan on returning to 16-bits once I can get my hands on an easy to implement processor, but for now the 6502 will be good enough.

I’ve also revised what exactly I’m making. I still want to make a retro console, but that doesn’t mean I can’t also make a retro computer. Or multiple of both of those. So, here’s my plan:

  • I’ll make 2 8-bit computers:
    • A Desktop running at 8 MHz, called the Neutron Station (Model N8D)
    • A Handheld running at 2 MHz, called the Neutron Pad (Model N8P)
  • I’ll make 2 8-bit consoles:
    • A stationary console running at 8 MHz, called the Neutron Box (Model N8C)
    • A handheld console running at 2 MHz, called the Neutron Mate (Model N8H)

Yep, 4 models. And 2 of those will need built-in screens. How fun :D. The computers will share one memory map (which will be similar to but not compatible with the Commander X16), while the consoles will use a different memory map (because they have to account for the cartridge). All of them will have the same audio and video chip, which is still called the AVC, or Audio/Video Controller. There will be 64K of Video RAM.

The desktop will have 4 expansion card slots. The handheld computer will have 1 expansion card slot.

As for the consoles, they will need cartridge slots. As for the memory map, it is halved, then halved, then halved again. It starts out with a 16 KiB internal RAM area, followed by 8 KiB MMIO, then a banked 8 KiB area for cartridge RAM (this is the same as High RAM in the computers). This is then followed by the cartridge 16 KiB Low ROM/Flash, which is banked similarly to the cartridge RAM (meaning you can have up to 4 MiB in here!). Finally, at the end of the memory map, is the 16 KiB of cartridge High ROM/Flash.

Okay, I said a lot in this post. And it’s the middle of the night, so I’m tired. I’ll see y’all later, I guess. Have an awesome day!


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?)


I messed up.

Okay, maybe that’s sugarcoating it a bit.

But really, I really regret how much I have messed up this entire school year, my first year of college. First quarter? Failed precalculus because I’m a dumbass who can’t remember to do his homework over the weekend. Second quarter? Passed with thin margins. This quarter? Well, it looks like I’m going to pass two of my classes, but then there’s Calculus I, where I only got 5% on the second test AND I know I forgot to do my homework. I am such an idiot. And even when I tried to fix things, either by taking my advisor’s advice and doing a “Smart Habits” thing to try and get better at, well, everything, or by taking my parents’ advice and follow a strict schedule, whatever makes me such a dumbass that I need to do all of this to not fail just circumvents it! I don’t get it! I messed up, I tried to improve, but somehow it just didn’t happen.

… I am probably going to lose my scholarships. And its my fault. And I just don’t know what to do.