Friday, November 5, 2021

DIY-A-Fake-Floppy-Drive Video

 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.


Obviously there's nothing groundbreaking here, but it was a way to pass the time.

Tuesday, September 28, 2021

SepTandy 2021: TRS-80 Repair Part Deux

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.

Tuesday, September 21, 2021

Septandy Video: Repairing an original TRS-80 Model I

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.


Spoiler: If I can get this machine running I think I'm going to try refocusing my DIY video project temporarily back towards the "retro video card" goal instead of going straight to a full computer. If things work out I'll explain why in a future episode.

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.

DIY-A-Fake-Floppy-Drive Video

 New video posted to Youtube, about hacking up a cheap Gotek floppy emulator into a self-contained retro floppy drive substitute for classic...