Monday, February 1, 2021

The Dino128 Lives!

Or a tiny little piece of it does, anyway.

Here's the latest in the DIY video saga, in which I pedantically explain how I've turned the "toy" prototype of my video hardware that could only display bitmapped graphics stored on a ROM into an honest-to-goodness video system which supports ROM'ed and user-defined character sets in text mode, real bitmapped graphics, and a unified shared memory architecture when used with a 6502 CPU.

Skip to the end to see the breadboard running unmodified diagnostic software for the Commodore Pet 2001 on the attached CPU.

Of course, at this point it's *just* the CPU hooked up to a Commodore PET-like arrangement of RAM and ROM, to actually be useful there will need to be some I/O hooked up. One step at a time...

Monday, January 25, 2021

Video project update...

 ... coming to a badly neglected Youtube channel near you soon, hopefully.

Character generation is now working on the video processor. (This is not a bitmap test plate, this is a 2000 byte buffer being rendered using an 8 row by six column character font derived from the character generator ROM used by the Commodore LCD portable prototype from the mid-1980s. 64 character and lower text modes use standard byte-wide fonts.) Better yet, character generation is being done using a "unified" memory model, no dedicated character ROM. This means software defined characters in RAM might actually be a done deal.

Bonus: this doesn't require any more chips than the other way. Assuming I'm not utterly, completely, hopelessly wrong about my prospects of getting this interfaced to a 6502 CPU we've essentially jumped from Commodore PET to VIC-20 levels of technical sophistication. Hooray?!

Tuesday, January 12, 2021

Still plugging away on the Next Big thing...

 I was meaning to throw together a silly unboxing-type video this weekend, but, well,

 A: I remembered I don't really like unboxing videos that much, and

B: I instead ended up doing a deep-dive into code cleanup and actually trying to lay down a rigid specification set for what I was trying to accomplish.

Item B: is actually the valid excuse, so I guess I'll speak quickly about that. I initially ordered the parts intended for expanding the "Video Card" prototype several weeks ago, and while waiting for them I ended up exploring all sorts of nitpicky side experimentation and refinements. Some of them were worthwhile, and some of them were "feature creepy" or turned out to not be particularly reliable. The reasons for some of the latter may be because of the limits of having the prototype living on a breadboard, but the TL;DR boils down to that a lot of stuff that seems to work well at 12mhz starts getting flaky above that. I kept flirting with higher clocks in part because part of me was concerned that not supporting a full 80 column mode might be a problem; I did have a "7-bit" 80 column mode that works for graphics at 12mhz but it barely fit horizontally on most CRT monitors, and I also ran into a rude surprise when I tried to add the small amount of logic still needed to be able to run in character generator mode.

A possible flaw in the code I'm using is the way it uses interrupts is kind of expensive; it uses one to trigger the Hsync pulse, sleeps, and uses a second interrupt to switch to the active line rendering code. There is a fair amount of overhead for interrupts on the AVR; it has to save a bunch of registers at the start of an interrupt and restore them when the interrupt is over, and the overhead from that is constant in terms of clock tick overhead; if you run a lower clock it takes longer. This eats into the "active time" I can have per line. At 12mhz the overhead is still acceptable, in the sense that you can fill an active area that runs roughly bezel-to-bezel on older CRT monitors, but if you *fill* that space it leaves very few ticks to do anything else. The prototype in the videos so far is essentially always running in "graphics mode"; to do "text mode" there's going to be a *tiny* bit more overhead in setting a "which row am I on?" register. As it turns out doing 560 pixels at a 12mhz pixel clock essentially absorbed *all* the available CPU ticks, I was having issues fitting the character row in there so it wouldn't overrun the next interrupt. Thus, essentially, I could do a 7 bit 560 pixel bitmap mode, but there's zero point in that. So I ditched it.

Since I still had two control lines implementing 4 possible control states for the shift register control GAL I then switched to experimenting with a "super low" pixel clock to emulate something like the VIC-20's 22 character wide display. The weird thing I ran into, though, is about half of my LCD monitors *hated* this mode when done with a 4mhz pixel clock. (A mono CRT was fine.) Worked okay on a large TV and relatively ancient portable, but a newer smaller LCD with composite in and an NTSC-to-HDMI adapter would fritz out and lose video. Wasted too much time on this, I *think* the problem is that the 4mhz pixel clock might be freaking these devices into thinking they see a phantom colorburst and their scalers then react badly. I then tried for laughs programming a 2.5x (instead of 3x) clock divider into the GALs, and ran into a separate issue where on every other line the resulting pixel lines were offset by one subpixel timing and displayed raggedly. To cut to the chase, well, I've decided I don't care for super-low-res mode anymore. I *might* be able to fix the 2.5x clock issue by coming up with some pulse-stretching logic, but instead I've made the executive decision that it's more trouble than it's worth. The 2x "32 column" 6mhz clock is rock stable and if you *really* want a 22 column display it'll render fine, if a little vertically stretched, in that.

So... here's the compromise I finally came up with, and what I'm planning to move forward on:

  • Sticking with 3 pixel clocks; 12mhz, 8mhz, and 6mhz. They render beautifully and the code works.
  • MCU will remain at 12mhz. Was pondering the idea of using an 18mhz or even 24mhz clocks so I could cut down on the interrupt overhead time, but there really isn't a point. I'll leave overclocking the AVR for a future VGA variant.
  • I brought the 7-bit mode back from the dead in the form of a *six bit* mode. This gives a perfectly legible 80 column screen in only 480 horizontal pixels in the 12mhz clock mode. (IE, 80 columns actually renders slightly narrower than 64's 512px.) The downside of this mode is it will not have selectable characters per line, it will support only 80 because I can't use a loop anymore, it has to use an assembly macro. Framebuffer start is still arbitrarily selectable and I think I should still even be able to do the "windowing" thing if the character buffer is actually larger so, well, don't care, it's good enough. If I want to support emulating an 80 column Commodore that will mean I have to come up with a six bit wide version of the Commodore PETSCII character set, but, too bad.

Anyway, at that point that's what I'm shipping for the video section. Since then I've been puzzling over the computer specs. Still finalizing that, especially what I want to aim for for memory banking, but on the bright side I think I've come up with a "clever" idea that *might* let me support user-definable character sets along with sharing a single ROM between the CPU and the video system. Still fleshing it out but, well, I think I know what I need to prototype next.

Saturday, January 9, 2021

From Video Card to a full computer...

 I doubt anyone actually reads this blog, but just in case here's a link to the latest in the "Video Card Saga", in which I try to explain how GALs, an old-fashioned little hunk of programmable logic, are magical.

At this point the project is going to turn into a quest to actually build a simple 8-bit computer around this video system and a 6502 CPU. Parts have been purchased, I think I'm going to call it the "Dino128", the 128 because of the 128KB RAM chip I'm going to try first in the prototype, and "Dino" because the system is going to be based roughly on the Commodore PET, and, well, anyone old enough to remember a little town named Bedrock will know the proper name for a prehistoric pet.

Saturday, January 2, 2021

It Begins: DIY Video Card Saga

 I've started a new series about an attempt to build a homebrew memory-mapped video card. Here's a link to the playlist that has the first couple videos, I'll add further episodes as they happen. Meanwhile here's the first and second episodes. Part1:

Part 2:

Monday, December 7, 2020

The Tandy 1000 Saga: catching up.

I'm bad at blogging.

There, just got that out of the way.

Since I last updated this blog over a year ago I've uploaded a few more YouTube videos on the subject of the memory board project I initially started a few months after getting a bare Tandy 1000 EX in the middle of 2019. A lot has happened since then. Here's the latest video, in which I'm demonstrating the capabilities of my latest and perhaps ultimate variation of a Tandy 1000 EX/HX expansion board:

Here is a link to a playlist of the previous videos.

In short, the current version of the board, which is implemented using a couple of GAL (Generic Array Logic) chips in order to fit everything (tightly) into the space available while retaining the use of through-hole parts for easy assembly, includes the following features:

  • Expands base memory of a bare 1000 EX/HX to 640K
  • A "spare" 128k is available to be mapped into the upper memory space between C0000 and EFFFF, with several switch-selectable options to optimize utilization.
  • Two additional sockets for 512k SRAMs are available and can be populated to provide 1MB of EMS memory. Page frame location is adjustable.
  • 44 pin laptop PATA connector to be used with either a CF or SD adapter to provide hard disk storage via a single-chip XT-CF-Lite implementation.
  • In-system programmable Flash ROM for the XTIDE BIOS, location is switch adjustable.
  • Dallas 1215/1315 "zero-slot" clock compatible with Radio Shack's original "Smartwatch" option.
  • Dual 9-pin 16550-compatible serial ports; switch settings allow one to use a nonstandard IRQ to free up IRQ 3 for other expansion cards while working as a dedicated mouse port in conjunction with the CuteMouse driver.
  • Expansion passthroughs compatible with the original Radio Shack cards; can be used with genuine Plus cards or with an ISA adapter for network or VGA cards.
  • With the latest GAL programming and the aid of a jumper wire can override the built-in DOS-in-ROM in the Tandy 1000 HX, freeing up memory space for use as UMB or EMS page frame. Also allows relocation of XTIDE BIOS to F0000, which is very useful if an option card that has a ROM (like a VGA card) is installed.

Anyway. This board is currently not for sale; I don't think I have the bandwidth in my life to produce it, alas. But it's been an interesting project, and very educational.

Monday, November 18, 2019

Say Hello to the Tandy 1000 SUX!

I've uploaded a new video to my Youtube Channel, it's embedded below. As usual, I don't know how to keep things brief, but at least I tried to keep it moving.

The Dino128 Lives!

Or a tiny little piece of it does, anyway. Here's the latest in the DIY video saga, in which I pedantically explain how I've turned ...