Wondering what you think of this computer design

[WillisBlackburn]

What era is this targeting? You refer to the Atari For a retrocomputer in the Atari / Apple ][ / TI-99 / TRS-80 class, if that is the intention then my feeling is it appears way too 'busy'.
There's so many keys that it seems more like an IBM PC class machine than an 8-bit. For instance you have a lot of keys next to the space bar eg Alt and the pulse(?) one. Also the column of unassigned keys at the RHS edge seem superfluous, as do the cursor keys when you could use WASD as mentioned above. Keeping production costs low in the 8-bit era was a big influence on design.
Regarding the status indicators- the peripherals of the era often had the LED on the device (for example the Disk ][ floppy drive) so there would be little reason to replicate the disk access LED on the system console unit except for invoking an anachronistic 'blinkenlights' aesthetic.

The keyboard only has 65 keys which is one less than the Atari 800! Remember the Atari had cursor keys too, between the semicolon and return keys. The column of “unassigned” keys are function keys. On the actual thing they’ll be labeled F1-F4.

Computers that had built-in disk drives accessible from the side like the Apple IIc and Amiga 500 (and this one) put the disk busy LED on the top. It would not have been visible on the side!

 

[WillisBlackburn]

I guess I don't really have much in the way of opinions about the case without any insight on what's actually inside. Is this "retrocomputer" a modern microcontroller/SOC (or an FPGA) just designed to "feel" like an old-fashioned computer, or does it use real retro tech? (Granted with the death of the Z80 the options for the later are rapidly diminishing, but the 6502 is still kicking.) Is it intended to emulate any existing retro platform or is it just its own thing? I mean, I assume the use of MikroBus means that answer to the first question is obvious, but I suppose the second could still be up in the air.

If I have to be brutally honest, personally I'm pretty cool on "modern microcontroller in a retro box" projects simply because they're up against some pretty brutal competition in the shape of Raspberry Pi-style offerings, which have a pretty well established ecosystem already in terms of projects and howtos for interfacing with the standard Pi header. (Many of the third-party Pi knockoffs make a point of being largely compatible with it.)

It’s not an emulator and there is no microcontroller in the box. It is an FPGA design. It uses the Arlet/Hoglet/BigEd 65C02 soft core CPU but most everything else including the graphics and sound systems is custom hardware created by me. It is for sure inspired by the Atari 8-bit machines (we all know they were awesome) but is not compatible with them. I didn’t see a need for that: the Atari machines exist and are easy to obtain.

Some people will take issue with the soft core CPU. But if you want to do your own graphics and sound—and that was the whole point of the project—you’re going to need an FPGA. And once you have that, putting a physical CPU on the board just increases cost and complexity. The CPU consumes only 2% of the resources of the low-end FPGA I’m using. It delivers the same user experience and is effectively free, which makes the machine more affordable.

I could have written the whole thing as a software simulation on a Raspberry Pi, but why bother. It would just be a Pi.

 

[acgs]

The keyboard only has 65 keys which is one less than the Atari 800! Remember the Atari had cursor keys too, between the semicolon and return keys. The column of “unassigned” keys are function keys. On the actual thing they’ll be labeled F1-F4.

Computers that had built-in disk drives accessible from the side like the Apple IIc and Amiga 500 (and this one) put the disk busy LED on the top. It would not have been visible on the side!

I agree with not using abbreviations to label the LEDs. Since you aren't sure where this project will take you, if it is an either/or choice, I also recommend not using words, since selling the system in other countries could lead to interest in foreign language editions. So the icons seem to me to be the best way to go if I had to choose. I'd also use the icons on the slots to match the LEDs up to them. But, why don't you use both? An icon above or below the word gives the best of both worlds and still makes the labeling less confusing.

If you decide to have English words, you might do well with vertical labeling. You seem to have room to spare above each LED and could easily write:

P
O
W
E
R
(|)

for example (the last thing is supposed to be the standard Power Icon). It would also be possible to make a little snap-in panel out of this part of the case. Then you could make up differently-labeled panels depending on what styles are in demand.

This does look like a good fit for a crowdfunding project. It would give you an idea of how many units will be worth making in the first place and possibly help you decide the best manufacturing methods to use.

 

[Istarian]

@acgs English was a common denominator and remains so now. And there is little to no reason to change thaf, especially if it is the native language of the product designer/manufacturer.

That is especially true when dealing most Western european languages whose "modern" forms are aubstantially influenced by Latin.

Using Google Translate:

floppy disk (English)
disquette (French)
Diskette (German)
disco flexible (Spanish)
disquete (Portugese), possinly 'os disco flexível' if described in writing or outside of the usual context

 

[Eudimorphodon]

The keyboard only has 65 keys which is one less than the Atari 800! Remember the Atari had cursor keys too, between the semicolon and return keys. The column of “unassigned” keys are function keys. On the actual thing they’ll be labeled F1-F4.

FWIW, I think the keyboard is perfectly fine for a machine intended to be a "new" platform. One of the itchy problems that comes up if you are trying to make a keyboard for a machine that explicitly emulates an older machine is the differences with regard to the symbol placement; if you're just making a "new" machine you might as well just use the layout dictated by modern keycaps you can get for pennies, right?

A lot of small computers had relatively minimalistic keyboards. This might have been about keeping the BOM cost down and keeping the scanning logic simple. But the design choices made there have ripple effects in how well they work for different use cases. Commodore's "shifted arrows", for example, are sort of hostile for full screen editing or games where you'd want to move in all four directions evenly. I'm pretty sure people who learned to type on a Selectric would find the TI-99's positioning of quote marks and question marks frustrating.

If you look at the keyboard layouts on most machines that trace their origins to the 1970's they have symbols like " ' ( )* : , etc, in completely different places than the modern PC layout, and there's actually a very legit technical reason why the symbols were placed like that. If you look at an ASCII chart the choices of the symbols on the number keys (and the pairing of symbols like the colon and asterisk) was dictated by their bitwise relationship; for those 16 keys, 32 codes total, the shift key controls bit 4 (numbering from zero). This was a handy shortcut when building keyboard encoders. (Likewise for the next block of 32 keys, IE, the letters and the remaining symbols, 64 total, shift controls bit 5.) The bonus you get out of using an "ASCII" keyboard layout like this is you can use "math" in your keyboard scanner instead of a full lookup table. For instance, here's a TRS-80 keyboard's *physical* matrix layout:



You can scan this keyboard by literally just breaking it into two chunks, an 8x4 letter matrix and 8x2 number matrix, converting the position of a pushed button within each matrix to a number between 0-31 or 0-15 (respectfully), adding or subtracting a leading bit based on the state of the shift key, and adding 64 or 32 (letters/numbers). The result is the ASCII code, no lookup table required. This isn't much of an advantage if you're using a controller chip that has enough ROM for a lookup table, but it's pretty darn handy of you're either constructing a keyboard scanner completely out of TTL or trying to write a software scanner for a computer that might have only a few K of memory.

Because ROM got so cheap, so fast, by the beginning of the 1980's the advantages of this encoding went away and most keyboards reverted to the symbol placement favored by electric typewriters. (And physical keyboard matrices became arbitrary positional grids instead of being ordered like this.) This does make me want to crawl through AliExpress now and see if anyone still prints keycaps with the ASCII encoding scheme, though; I assume you'd have to custom order it, it'd be fun to be wrong.

It’s not an emulator and there is no microcontroller in the box. It is an FPGA design. It uses the Arlet/Hoglet/BigEd 65C02 soft core CPU but most everything else including the graphics and sound systems is custom hardware created by me.

So basically it's a Spectrum NEXT or C64 Ultimate but based on a proprietary architecture... so more like the Commander X16, which has most of what anyone cares about in the VERA FPGA, but you're not bothering with the separate physical parts that let's the Commander folks pretend it's not an FPGA machine. Okay. Well, good luck, then.

But if you want to do your own graphics and sound—and that was the whole point of the project—you’re going to need an FPGA.

I mean, strictly speaking, no, an Apple II has graphics and sound and doesn't need an FPGA, but yes, I get it, if you want a bunch of sprites and whatnot you're not going to want a circuit board the size of a desk.

 

[Istarian]

Fair enough, the word choice might have been a bit aggressive.

A lot of small computers had relatively minimalistic keyboards. This might have been about keeping the BOM cost down and keeping the scanning logic simple. But the design choices made there have ripple effects in how well they work for different use cases. Commodore's "shifted arrows", for example, are sort of hostile for full screen editing or games where you'd want to move in all four directions evenly. I'm pretty sure people who learned to type on a Selectric would find the TI-99's positioning of quote marks and question marks frustrating.

At the end of the day just using a nominally standard PC keyboard that has different keycap shapes, different key widths, or minor placement variation is a PITA, because your 'muscle memory' puts your fingers in the wrong place.

 

[WillisBlackburn]

If you look at the keyboard layouts on most machines that trace their origins to the 1970's they have symbols like " ' ( )* : , etc, in completely different places than the modern PC layout, and there's actually a very legit technical reason why the symbols were placed like that. If you look at an ASCII chart the choices of the symbols on the number keys (and the pairing of symbols like the colon and asterisk) was dictated by their bitwise relationship; for those 16 keys, 32 codes total, the shift key controls bit 4 (numbering from zero). This was a handy shortcut when building keyboard encoders.

I never realized that before, but it makes sense! People who have never used an Atari 8-bit always think it's weird that the double quote is shift-2. And I definitely notice that my Apple II has '(' and ')' on 8 and 9 instead of 9 and 0, every time I try to type something on it, but I never thought about why. I guess eliminating the space bar and using shift-0 for space was a bridge too far even for the keyboard cost-cutters.

So basically it's a Spectrum NEXT or C64 Ultimate but based on a proprietary architecture... so more like the Commander X16, which has most of what anyone cares about in the VERA FPGA, but you're not bothering with the separate physical parts that let's the Commander folks pretend it's not an FPGA machine. Okay. Well, good luck, then.

Yeah, you see the problem. Once you add an FPGA, you can't really claim it's authentic retro hardware. The's a similar situation with FPGA-based drop-in replacements for the SID and TMS9918A and other classic computer ICs, especially ones that include capabilities beyond the original hardware. Those are impressive projects, and really useful for someone who wants a drop-in video or sound solution for a DIY computer. But from a system design perspective, I don't really see the point in saying it's okay for the video generator, video memory bus, and video RAM to be in an FPGA, but not the CPU, CPU bus, and system memory.

To their credit, the X16 designers did try to stay true to their design philosophy by using a very low-end FPGA that only has enough resources for the VERA design and couldn't possibly implement the entire computer. There's also a microcontroller on the X16 board, and again, they used a low-end part, so there's no way it can gobble up the rest of the design. But you only have to look at the X16 board to see that insisting on drawing physical boundaries between these parts on the PCB really drives up the BOM.

I mean, strictly speaking, no, an Apple II has graphics and sound and doesn't need an FPGA, but yes, I get it, if you want a bunch of sprites and whatnot you're not going to want a circuit board the size of a desk.

That's right. A video system build out of discrete logic chips would either be on par with the Apple II or ZX80 (not really very exciting), or would look like the Amiga prototype: not something that is shippable as a product. The practical choices are either use an existing SPI or I2C video driver, use an RP2040 or similar to generate the video in software/PIO, or build my own FPGA implementation. Of those, the FPGA route seemed the most authentic. It really is the same creative process that the the ANTIC and VIC-II designers followed, and ultimately both produce a custom hardware video driver.

 

[Istarian]

@WillisBlackburn People just love to nitpick for some reason; something of which are are all probably guilty of doing at least some of the time.

I think Memory (RAM or ROM) is the one thing most people don't really care about in this area.

Aside aside from some sort of peculiar memory architecure it doesn't really make much difference how the bits/bytes are actually stored as long as the external interface is compatible and consistent. ---- You could literally stream data to and from a serial ram chip as long as the rest of systems sees an 8-bit or 16-bit interface with proper access timing.

I would love to see nothing but discrete logic and minimal complexity SSI/MSI/LSI but some point the fight over programmable logic is jusr absurd. Many systems were utilizing PAL, GAL, ULA, Gate Array(s), or other PLDs of some sort even back then.

I doubt anyone was implementing discrete video circuitry for very long unless it was about cost savings or wanting functionality they couldn't get from off the shelf parts.

Generating your video output in software using a full blow computer is kinda blech imho. Using a CPLD or FPGA is more in the spirit of retrocomputing, imho.

-----

The Raspberry Pi Pico may technically be a "micrcontroller" board, but it has more in common with an ESP32 than an 8-bit PIC or AVR.

Which is say that it has full-blown 32-bit (ARM Cortext M0+) processor cores clocked at over 100 MHz and more built-in RAM than the "computer" it's being connect to... which just makes your 6502 or Z80 more like bespoke accessory compute...

 

[Eudimorphodon]

I never realized that before, but it makes sense! People who have never used an Atari 8-bit always think it's weird that the double quote is shift-2. And I definitely notice that my Apple II has '(' and ')' on 8 and 9 instead of 9 and 0, every time I try to type something on it, but I never thought about why.

Yeah, I remember being a little gobsmacked by this when I found out about it. (I'm old enough to remember it just being "a thing" that computer keyboards, for whatever reason, had the symbols in different places than most typewriters, but it took a while for me to really put 2+2 together as to the actual reason for the placement.)

I guess eliminating the space bar and using shift-0 for space was a bridge too far even for the keyboard cost-cutters.

I think on the original TRS-80 Model I's ROM keyboard driver shift-0 actually does work as a secret spacebar; on the Model III (and disk-based Model Is with a lowercase mod) they overrode shift-0 to be a caps lock (since the keyboards lack a dedicated key.) I assume the same would be true on really early parallel-encoded ASCII keyboards used with TV typewriters or whatnot, but... like I mentioned, even by the mid-late 70's a lot of those started using encoder chips with ROM lookup tables as parts of their state engines, so it's not a sure thing if you see a keyboard that has the "ASCII Layout" of the symbols that the physical matrix is also arranged in ASCII order.

(The downside of the physical matrix matching ASCII order is it makes the trace layout for the PCB obnoxiously convoluted. A positional matrix is cheaper as long as you're willing to spend the memory on the scanner... although you can still win by going with the ASCII symbol order because you can get away with just having one 8x8-or-whatever ROM table for the unshifted board and still apply the modifiers mathematically, instead of needing a separate table for each modifier.)

That's right. A video system build out of discrete logic chips would either be on par with the Apple II or ZX80 (not really very exciting), or would look like the Amiga prototype: not something that is shippable as a product.

FWIW, I'm personally enamored with simple 70's vintage video systems. There's a project I started five years ago that I keep not finding any time to iterate much on that I keep fantasizing about building into a full retro computer that's... mostly discrete, in the sense it uses all through-hole parts. (But they're all parts you can buy new off the shelf, at least for now.):

The goal is basically imagining something you *could* have built in the 1970's, if VRAM was a lot cheaper than it was. A complete computer built around this using a Z(1)80 or 6502 would end up with a PCB board around the same size as an Apple II's but in principle it would be able to do quite a bit more. The design is a slightly re-imagined character generator/tile based system that can also act like a clean linear framebuffer, and it also, in theory, could emulate the weird bitmapping of a lot of retro machine's framebuffers, IE, you could set it up to display Apple II or Commodore 64 Hires content (in monochrome) with no hardware changes, and even mix them on the same screen (horizontal slices). The design uses GALs to cut the chip count significantly, but you could in principle build most of it out of pure TTL...

The cheat is, yes, it does use a microcontroller. Buuuut, it's not something like a Pi Pico that's (much) more powerful than the main CPU, at least. It uses an Atmega324 (part of the AVR 8-bit CPU family in the original Arduino boards) programmed to act (mostly) as the CRTC. IE, it runs a tight "beam-chasing" program to do address generation during the active pixel area, and handles sync; the actual frame buffer RAM is entirely in the CPU's address space. You could pull this part out and with slight modifications replace it with a vintage 6845 or similar CRTC; the reasons I went with it is A: you can get them new, and B: Since it is programmable that opens the door to doing some clever things like being able to mix video modes or do weird/arbitrary memory interlacing without adding CPU overhead. Basically by adding a path to send instructions to it at runtime from the main CPU it could act something like the ANTIC in an Atari 8-bit.

(Another thing to note here is that people *were* actually building systems like this in the 1970's. Don Lancaster, creator of the original 1973 TV Typewriter, published a book called the "Cheap Video Cookbook" and created designs for video systems, like the TVT-6, that used a combination of software and hardware tricks to use a contemporary CPU chip like a 6502 as a video address generator. This is also basically the same technique used by the Sinclair ZX-80/ZX-81. If using the modern AVR really bothered you it would also be possible to replace it with a 6502... which, actually, might be really apropos if the main CPU were also a 6502; you could do the trick Commodore used in some of their disk drives where the two CPUs have the bus on the opposite sides of the Phi clock...)

But yeah, obviously this, if it ever happens, is going to be bigger and more expensive than a "virtual" system built on an FPGA, and yeah, no sprites. I'm sure if I ever end up building it it's just going to be for me because while it should be as, if not more, capable of doing video games as an Apple II, CGA, or even... I dunno, a VIC-20?, it's not going to remotely compete with VERA.

 

[WillisBlackburn]

(The downside of the physical matrix matching ASCII order is it makes the trace layout for the PCB obnoxiously convoluted. A positional matrix is cheaper as long as you're willing to spend the memory on the scanner... although you can still win by going with the ASCII symbol order because you can get away with just having one 8x8-or-whatever ROM table for the unshifted board and still apply the modifiers mathematically, instead of needing a separate table for each modifier.)

My design uses a TCA8418 keyboard scanner. It's a $1.50 IC that sends keyboard events over I2C. I decode and do the conversion to ASCII in hardware. The 6502 just reads an address to pop the next ASCII code off the FIFO. After reading the FIFO, it can access another register to see what modifier keys were in effect when that key arrived, so you might get 'A' if the user is holding shift but if you look at the other reg you can find out if they were also holding another modifier key. The CPU can switch the keyboard into raw event mode and also read the current state of every key from a 10-byte bitmap. (The TCA8418 supports 80, so 10 bytes.) So for a keyboard-controlled game you can just look at the key states and ignore the FIFO.

The goal is basically imagining something you *could* have built in the 1970's, if VRAM was a lot cheaper than it was. A complete computer built around this using a Z(1)80 or 6502 would end up with a PCB board around the same size as an Apple II's but in principle it would be able to do quite a bit more. The design is a slightly re-imagined character generator/tile based system that can also act like a clean linear framebuffer, and it also, in theory, could emulate the weird bitmapping of a lot of retro machine's framebuffers, IE, you could set it up to display Apple II or Commodore 64 Hires content (in monochrome) with no hardware changes, and even mix them on the same screen (horizontal slices). The design uses GALs to cut the chip count significantly, but you could in principle build most of it out of pure TTL...

I'm kind of doing the same thing, except my "target year" is 1983. I want to make something that *could* have existed then, even if it wasn't cheap. A 6502 home computer from that year wouldn't have 256-color graphics and 8-voice sound. But the Sun 1 and several PC video boards displayed 256 colors, and 8 voice sound existed in arcade machines. So the hardware was available.

But yeah, obviously this, if it ever happens, is going to be bigger and more expensive than a "virtual" system built on an FPGA, and yeah, no sprites. I'm sure if I ever end up building it it's just going to be for me because while it should be as, if not more, capable of doing video games as an Apple II, CGA, or even... I dunno, a VIC-20?, it's not going to remotely compete with VERA.

It doesn't have to, though!

 

[Istarian]

That just seems like a rather over-complicated "solution" to handling a keyboard imho

It might not even a be a "keyboard scanner" at all, because there is no 'scan' happening if you can directly read a single key and see what it's state is without examining the entire matrix.

-----

The classic approach drives the matrix with a bit pattern enabling a single row/column at a time and inspecting the data read back.

A simple example would be a single group of N buttons or switches attached to GPIO (General Purpose Input/Output) lines. The I/O lines are pulled to a logic HIGH or LOW and when a button is pressed thr logic state is reversed by voltage applied by connecting the circut formed by the switch and electrical path.

 

[WillisBlackburn]

That just seems like a rather over-complicated "solution" to handling a keyboard imho

It might not even a be a "keyboard scanner" at all, because there is no 'scan' happening if you can directly read a single key and see what it's state is without examining the entire matrix.

-----

The classic approach drives the matrix with a bit pattern enabling a single row/column at a time and inspecting the data read back.

That's exactly how this works. The keyboard is a 10-column, 8-row matrix. The TI TCA8418 chip scans the matrix and sends key up/key down events over I2C. I used it because it's really cheap and does the business, and it enables me to control the keyboard with just 2 FPGA pins, vs. needing to use 18 pins and run a ribbon cable to the keyboard PCB. As an added bonus, it's I2C, so I can put an LED controller on the keyboard PCB and control it with the same two wires. It's worked out really well.

What I was describing is what happens in the FPGA after it gets the I2C key up/key down events from the TCA8418.

 

[whartung]

The big thing about the vintage graphic computers was that the video system dominated the design, just about every other design decision was done in the shadow of the video system. The software basically got to run in the idle periods between when the TV beam was moving back, scan line interval, vblank, etc. Many systems performed much faster with the video system "off".

So, in the end you got a nice video system with a few spare cycles to run your software, not the other way around.

 

[WillisBlackburn]

The big thing about the vintage graphic computers was that the video system dominated the design, just about every other design decision was done in the shadow of the video system. The software basically got to run in the idle periods between when the TV beam was moving back, scan line interval, vblank, etc. Many systems performed much faster with the video system "off".

That's the point that Eudimorphodon was making about the Commander X16. The components that most influence the user experience, its video and sound capabilities, are in the FPGA-based VERA hardware. The video and sound were really what made every vintage computer unique. They all used the same processors. So it makes sense to spend your R&D budget on video and sound in order to gain an advantage over your competitors.

This is the layout of my computer's FPGA. This is just a snapshot; it changes a bit every time I build it. The graphics hardware is purple and the sound is yellow. I nudge the placement software so it prefers to put the graphics in the "bottom" half of the FPGA, but is puts some of the sound stuff there too because it wants it to be close to those tall yellow blocks, which are hardware multipliers. Digital audio generation is basically a multiplication pipeline.

The 65C02 is orange. It's tiny. You can see that the computer is really a video and sound generator with a small embedded CPU.

The computer outputs 480P video over HDMI, so the pixel clock is 27MHz, and I use the same clock for the CPU. It's the simplest strategy from a design standpoint, and I think it's authentic: the Atari 8-bit computers, Commodore 64, and Apple II all had clock speeds that were tied to the NTSC color subcarrier frequency, about 3.58MHz. They had to divide that clock down to something that 6502s and RAM chips of the period could handle. I could divide 27MHz down, but why bother, it would just make the computer slower for no good reason. Clocking the CPU at 27MHz means that even BASIC programs run at a reasonable speed.

 

[Eudimorphodon]

That's the point that Eudimorphodon was making about the Commander X16. The components that most influence the user experience, its video and sound capabilities, are in the FPGA-based VERA hardware. The video and sound were really what made every vintage computer unique. They all used the same processors. So it makes sense to spend your R&D budget on video and sound in order to gain an advantage over your competitors.

FWIW, this is actually kind of why I set the bar for my project in the 70's instead of the 80's. The video system I built does have simple "tile" functionality (you could also call it redefineable characters) so it will support moving custom glyphs around the character grid (the VIC-20 was the most widespread/popular example of a machine that did that without having sprites I could think of off the top of my head; the TED chip in the C16/Plus4 is also in this category`) which works pretty well for "Space Invaders" type games, but other than that it's not a graphics accelerator, so making the machine do fancy stuff will mostly rely on clever programming.

(As I mentioned, the CRTC design *does* allow the thing to be switched to different video modes on a per-line basis, so if you wanted to do, say, a text adventure-type game that also had bitmap illustrations you could set up an arbitrary split between linear framebuffer and a character grid regions of the screen, and like the ANTIC in an Atari 800 the CRTC will handle processing the display list itself instead of requiring a timed interrupt every frame to make the CPU do it. But that's really not that far off from, say, the mode on the Apple II that let you set the top half of the machine to graphics with a text buffer at the bottom other than the split isn't fixed and you could potentially have more of them.)

Definitely don't take this as a criticism of the goals of your project, I just personally thought it would be interesting to see what could be done with a cruder system like that given, for instance, some of the impressive demos we've seen for similarly brain-dead hardware like CGA or the Commodore PET the last few years. Going completely ham on the graphics accelerator but keeping an 8-bit CPU to run the game logic just... kinda feels to me like it's more like a PC Engine/Super Nintendo(*) tribute than a personal computer? (Maybe the counterargument there is MSX2? Those were pretty rare outside Japan, though.) There's also just that factor of what really feels personally "nostalgic"; I'm just old enough to have imprinted on first gen systems like the TRS-80 Model I/III and the ubiquitous Apple II's connected to the white and green monitors because the school's too cheap to afford that many color sets, and, I dunno, I feel like that era's kind of neglected. Totally a me thing.

(* Yes, cue the big argument about whether the 65816 is *really* a 16 bit CPU or not. My actual answer is "yeah, kind of of, but measurably less so than the 8088"... point being it's a thing semi-reasonable people can disagree on.)

That's exactly how this works. The keyboard is a 10-column, 8-row matrix. The TI TCA8418 chip scans the matrix and sends key up/key down events over I2C. I used it because it's really cheap and does the business, and it enables me to control the keyboard with just 2 FPGA pins, vs. needing to use 18 pins and run a ribbon cable to the keyboard PCB. As an added bonus, it's I2C, so I can put an LED controller on the keyboard PCB and control it with the same two wires. It's worked out really well.

I just this week programmed an Arduino Nano to do this on a 7x8 matrix with its GPIO pins and output ASCII over serial; if you *wanted* ASCII or other more pre-processed output you could *probably* find a small MCU for about the same price that would also be able to talk I2C to the FPGA, but positional key down/release codes sound just fine for this application. It is a pretty neat chip how it has this self-contained matrix scanning engine but can retask unused matrix lines for GPIO expansion.

 

[WillisBlackburn]

Definitely don't take this as a criticism of the goals of your project, I just personally thought it would be interesting to see what could be done with a cruder system like that given, for instance, some of the impressive demos we've seen for similarly brain-dead hardware like CGA or the Commodore PET the last few years. Going completely ham on graphics accelerator but keeping an 8-bit CPU to run the game logic just... kinda feels to me like it's more like a PC Engine/Super Nintendo(*) tribute than a personal computer? (Maybe the counterargument there is MSX2? Those were pretty rare outside Japan, though.) There's also just that factor of what really feels personally "nostalgic"; I'm just old enough to have imprinted on first gen systems like the TRS-80 Model I/III and the ubiquitous Apple II's connected to the white and green monitors because the school's too cheap to afford that many color sets, and, I dunno, I feel like that era's kind of neglected. Totally a me thing.

It's not accelerated. The CPU has to write everything to the screen. It has 32 sprites, but they're not super-powerful. I wanted it to be able to display a 320x200 256-color bitmap, because I used that mode a lot on the PC in the early 1990s and liked its simplicity. And my computer can do that, but it requires nearly the entire 64K of video RAM. I think that anyone who really wants to program games will tend to use the tilemap modes.

VERA's video RAM doesn't live on the 6502 bus, so you have to write to it by poking control registers. I find that annoying, so I just let the CPU bank switch in the video RAM. You can bank in up to 16K into the range $A000-$DFFF. If you want to draw an entire 320x200 256-color image you'll have to switch banks a few times, but I think that most of the time people would be working with smaller bitmaps. A 160x100 256-color bitmap, and any reasonably sized tilemap, will fit.

You don't have to use $A000-$DFFF for video RAM. If you're not drawing to the screen, you can put regular RAM there, including the RAM hidden under the OS ROM in the $E000-$FFFF range.

I had the same middle school experience! We had a mix of Apple II+s and Apple IIes, some with color monitors and some with green screens.

Don't get me wrong, I love the Apple II. I have one! (Pictured, with the Gorilla green screen monitor my parents bought for me in the mid-1980s.) With just off the shelf parts, Woz delivered color bitmap graphics when everyone else had monochrome text. But all my graphics programing experience was on the Atari and VGA PCs, so I need more than 16 colors.

W

 

[Plasma]

It's not accelerated. The CPU has to write everything to the screen. It has 32 sprites, but they're not super-powerful. I wanted it to be able to display a 320x200 256-color bitmap, because I used that mode a lot on the PC in the early 1990s and liked its simplicity. And my computer can do that, but it requires nearly the entire 64K of video RAM. I think that anyone who really wants to program games will tend to use the tilemap modes.

You say it's not accelerated but it has hardware sprites and tiles? If the programmer doesn't have to draw those to the screen pixel by pixel, I would consider that acceleration. (I think that's fine; just trying to clarify.)

 

[Eudimorphodon]

It's not accelerated. The CPU has to write everything to the screen. It has 32 sprites, but they're not super-powerful. I wanted it to be able to display a 320x200 256-color bitmap, because I used that mode a lot on the PC in the early 1990s and liked its simplicity. And my computer can do that, but it requires nearly the entire 64K of video RAM. I think that anyone who really wants to program games will tend to use the tilemap modes.

Yeah, the memory issue is a big PITA with doing high res/colors with an 8 bit CPU. Honestly this memory pressure thing has made me consider using a CPU like the NEC V20 instead of an actual 8-bit. (I happen to have a tube of them lying around.) But once you open that can of worms you're looking at porting MS-DOS to it, and then you'll probably want it to be more PC compatible... meh.

(The thing that makes me sad about the V20 is it only has 8080 emulation built into it. Supposedly they built a version of it that expanded that to the Z80 instruction set, but it only shipped in a few PC-98 models, never as a catalog part.)

VERA's video RAM doesn't live on the 6502 bus, so you have to write to it by poking control registers. I find that annoying, so I just let the CPU bank switch in the video RAM. You can bank in up to 16K into the range $A000-$DFFF. If you want to draw an entire 320x200 256-color image you'll have to switch banks a few times, but I think that most of the time people would be working with smaller bitmaps. A 160x100 256-color bitmap, and any reasonably sized tilemap, will fit.

Yeah, VERA is a lot more like a TMS9918 (or the successor chips like the Yamaha V9938/V9958) than something like the VIC-II. It actually points to the real gap I was looking to see if I could fill with my video system, which is there are very few homebrew computers right now that have memory mapped video without using an FPGA or using RAM internal to a microcontroller. An RC2014-type single board computer that has "video" typically uses a microcontroller programmed to behave as a terminal, and even if you look at machines that are positioned as being "graphical" like the Agon Light they're still technically an eZ80 talking over a high speed serial line to an ESP32 microcontroller.

Ahwell. Until I actually get it beyond proof of concept it's not really anything, I suppose. I guess I just proved that you *could* build something like that today without using anything but through-hole and *not* needing one of those dual-ported RAM chips. (The few old-timey builds I've seen that do video almost inevitably use them instead of handing memory contention on normal RAM. This is why my video about the system concentrates on *sharing*, and showing you can do things like multiple read cycles for both framebuffer and character reads with a relatively trivial system for distributing accesses across clock phases, you don't *need* a CPLD or FPGA to do it. Yes, I'm using GALs, but what's programmed into them is just a few 4 bit counter/shift registers and comparitors.) Call it getting in touch with the inner Woz or whatever.

(Although don't get me started again on Woz... no, no, it's fine, we're talking about the Apple II here, not the Apple I...)

(Pictured, with the Gorilla green screen monitor my parents bought for me in the mid-1980s.)

We had that exact monitor when I was a kid; the first computer it was hooked to was a Coleco Adam, of all things.

 

[WillisBlackburn]

You say it's not accelerated but it has hardware sprites and tiles? If the programmer doesn't have to draw those to the screen pixel by pixel, I would consider that acceleration. (I think that's fine; just trying to clarify.)

By that standard, Apple II text mode, or ever Atari graphics mode, or the IBM MDA is accelerated. My computer doesn't have a text mode, it's just regular tilemap mode where the "tiles" are characters.

 

[WillisBlackburn]

Ahwell. Until I actually get it beyond proof of concept it's not really anything, I suppose. I guess I just proved that you *could* build something like that today without using anything but through-hole and *not* needing one of those dual-ported RAM chips. (The few old-timey builds I've seen that do video almost inevitably use them instead of handing memory contention on normal RAM. This is why my video about the system concentrates on *sharing*, and showing you can do things like multiple read cycles for both framebuffer and character reads with a relatively trivial system for distributing accesses across clock phases, you don't *need* a CPLD or FPGA to do it. Yes, I'm using GALs, but what's programmed into them is just a few 4 bit counter/shift registers and comparitors.) Call it getting in touch with the inner Woz or whatever.

You could prototype the logic in an FPGA and then decide if you want to build it out of discrete components. Once you have the logic described in Verilog (or VHDL, if you're a masochist), you can use open-source software tools like Liberty74 to compile it into a PCB schematic. This presentation has an example of using Liberty74 to build a 1,800-component PCB from Verilog.

We had that exact monitor when I was a kid; the first computer it was hooked to was a Coleco Adam, of all things.

I think it was popular because it was pretty inexpensive. I remember being like $80 or something. That was $80 in 1982 dollars or whatever, but still, good for a computer monitor.