New video posted to Youtube, about hacking up a cheap Gotek floppy emulator into a self-contained retro floppy drive substitute for classic computers using the standard 34 pin Shugart connector. With careful shopping the whole project can be done for under $40.
For once I actually delivered, here's part II of my TRS-80 repair saga. And spoiler alert, I actually managed to fix it.
I don't have much to add here other than taking a moment to marvel over the fact that the computer ran at all with such a major issue in the power supply. The plastics of these old machines are starting to turn into dust but those old TTL electronics are nigh indestructible almost fifty years later.
In case anyone actually reads this, long time no see.
I took a long hiatus from working on my homebrew video project because of mostly work-related stress. Realistically I'm not sure how much hobby time I'm going to have for a while now, but since it's September, which a subculture of the Internet refers to "SepTandy", I decided to post a Tandy related video or two.
In late August I saw a TRS-80 Model I keyboard in unknown condition for a "reasonable" Buy It Now price (by today's standards) and decided to bite. I already have a Model I, the unit I bought at a garage sale in a huge bundle back around 1990, but it's had a very rough life. Worst case I thought I might get some usable parts for that machine, which at the very least needs a new keyboard, best case I thought I might get a "runner", or at least one that could be made to run, without too much trouble. It turned out the machine I bought mostly runs, so the next few videos on my channel are going to focus on trying to fix it. Here's the first in the series.
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...
... coming to a badly neglected Youtube channel near you soon, hopefully.
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:
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.
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.
New video posted to Youtube, about hacking up a cheap Gotek floppy emulator into a self-contained retro floppy drive substitute for classic...
