- 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: http://6502.org/mini-projects/priority-interrupt-encoder/priority-interrupt-encoder.html
- 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
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.
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
Hello! 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.