Image Map Image Map
Page 10 of 10 FirstFirst ... 678910
Results 91 to 96 of 96

Thread: My "new" Northstar Horizon: where to get started?

  1. #91
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    2,898

    Default

    Quote Originally Posted by Dwight Elvey View Post
    There is a known timing error in the vertical retrace of the Polymorphic board. I causes a small amount of compression of the first line. It is more annoying than a real problem and it depends on the display monitor used. Some are more and some less forgiving on the timing.
    I don't plan on duplicating any of the actual circuitry of any of these boards, I'm just trying to figure out what it'd take to make something that's compatible enough in terms of attribute handling to run software targeted them, so that shouldn't be a problem. (Assuming I *do* actually get a stable video signal once this idea gets off the breadboard, that is. At the moment it's unstable enough you can produce stray dots by waving your hand over it like some kind of video theremin.)

    Does the PolyMorphic board have any kind of special attributes implemented in hardware? Poking through the manual it *looks* to me like it's basically just like a TRS-80 (with the lowercase bit present, not the silly 6th-bit shifting monkeyshines Radio Shack did on the original to save one RAM chip), with each byte in the 1K of video RAM always referring to the same point on the character grid, and with each character the lower 7 bits directed to the character generator if bit 8 isn't set, graphics characters generated otherwise. I don't see any kind of "Blink" timer or anything generated by the circuitry, is that correct?

    The Solid State Music board looks like it's basically a clone of the PolyMorphic board, except the manual indicates it has a switch that allows you to flip between displaying either graphics characters when bit 7 is set, or getting reverse video? I likewise don't think I see any kind of "Blink" functionality. Anyone able to confirm? (Also: it looks like from the schematic that the graphics/reverse video was directly controlled by a DIP switch, there's no software-switchable register to change this?) How did the console code for these boards display the cursor? Did they blink it in software according to a timing loop interval "on top" of the active character, or was it a static underline/graphics character rendered to one side of the active position?

    The PTC VDM-1 seems to be way more complicated than either of the two above. If I'm reading the manual correctly it has hardware functions to do the following:

    1: It has a "blink oscillator" with a period of about half a second.

    2: The "cursor" section confuses me. I *think* in the language of the manual any character with bit 7 set is a "cursor", and if a character is a "cursor" it's either displayed in solid reverse video, or it's reversed and un-reversed according to the blink timer?

    3: It has an 8-bit control register, half of which is the "windowshade", which dictates what line character display actually starts at (setting to "1111" would result in a blank screen?), and the other half selects where video memory "starts" in 64 byte chunks. (IE, it's an offset to be added to the top 4 bits of the 10 bit address lines, which roll over), thus allowing the screen to be "scrolled" by just moving the origin down. And:

    4: It has some flip-flops which get triggered by "CR" and "VT" control characters which tell it to blank to the end of line and end of screen respectively.

    If all this is true that'll make it *way* more of a pain to implement than the other two. (The first two things aren't a huge deal, I could probably generate a blink signal with the Amtel CPU, the third one is a significant pain that would require adding a latched register and a way to read it, and the last one is kind of a nightmare. Well, maybe not that bad, I think could program a GAL to handle it, but still a pain.)
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  2. #92

    Default

    I'm mostly sure there was no blink circuit. I don't recall a reverse video either.
    Dwight

  3. #93
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    2,898

    Default

    Quote Originally Posted by Dwight Elvey View Post
    I'm mostly sure there was no blink circuit. I don't recall a reverse video either.
    I spent some time puzzling over the assembly language listing in for a console driver in the Polymorphic manual and it does look like any cursor blink is entirely manual; the code copies whatever character is under the cursor to a storage location and writes a cursor character in its place. Didn't suss out the whole thing (my assembly skills are still very rusty) but I think it *might* time a blink based on the keyboard scanning intervals.

    I guess I need to do some research and see what the software support base for the various cards is. They're all kind of lumped together as cards "some of the first video games" ran on but the VDM-1 doesn't actually have graphics characters, so... how much of that software specifically relies on its other features like the blink/hardware scrolling/hardware blanking? (And do versions of those programs patched for the Polymorphic and SSM cards exist, making it kind of redundant to implement said features?)

    It looks like the SOL-20's video is a full copy of the VDM-1, so if I wanted to support SOL emulation I'd be stuck having to implement those bells and whistles.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  4. #94

    Default

    The Polymorphic machine does not know about keyboard scans. If you look at the Polymorhic video schematic, you'll see that the keyboard input is connected to an interrupt. The machine waits for a key interrupt to tell it that a key has been pressed. The keyboard is usually completely static in many cases, although some newer keyboards use a clocked keyboard chip, the Polymorphic is event driven by the key board's static output signal and knows nothing about how the keyboard operates.
    If there was any blinking function, it would need to be from a timer generated interrupt and writes to the display. The Polymorphic does have a time interrupt from the 60Hz line, while it is turned on.
    Dwight

  5. #95
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    2,898

    Default

    Quote Originally Posted by Dwight Elvey View Post
    The Polymorphic machine does not know about keyboard scans. If you look at the Polymorhic video schematic...
    Maybe I'm muddling it up with something that was in the terminal driver for the SSM VB1-B. (I keep switching willy-nilly between the PDFs.) I know one of them kept referencing an "Altair Standard" of having a parallel-encoded keyboard with 8 bits on Port 0 and status/strobe on Port1? I'm not sure if there's an interrupt involved with those for the keyboard scanning or if it's just polling, still too dumb to figure that out.

    Over my lunch hour today I decided to bang my head on the Atmel assembly wall again, and I've managed to hack the code I started with so it runs at a 12mhz clock instead of 16 and fixed the active line length to 64 characters instead of 80. (In the previous picture you might have been able to see how the first quarter of the bitmap was repeated as the line counter rolled over.) A 12mhz pixel clock gives a much more reasonable active area than a 16mhz one, of course. (The active area is a little over 2/3rds of the horizontal scan instead of only about 1/2.) I might need to tweak the sync pulse length, they're a *little* long if counting cycles in the simulator is accurate, but the picture still seems a lot more stable than it was. It could simply be that the lower clock speed is kinder to protoboard wiring, but it actually displays a rock-solid picture on my Apple IIc monitor now, which it wouldn't before. (It'd only sync on the LCD TV and the moons had to be properly aligned for that.) Even a tearing issue halfway down seems to have resolved itself.



    videotest_512pixels.jpg
    Last edited by Eudimorphodon; September 24th, 2020 at 01:10 PM.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  6. #96
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    2,898

    Default

    Progress, of a sort, on the “video card” project. (Maybe I should make a new thread for this.) I completely rewrote the driver software for the AVR CPU using open source Arduino code as the starter. (I’m using the “MiniCore” board set definitions for bare metal with a 12mhz clock for compilation.) I also decided to see if it would be possible to write line generation code tight enough to get rid of the address generation helper GAL *and* not unroll the pixel generation loop, and it turned out yeah, it /barely/ is, at least within the chosen design constraints.

    BA0AA52C-A0EE-47BE-AF6D-4F414C5A5C3D.jpeg

    I actually really like the result; there’s about a dozen and a half lines of embedded assembly for the line output, but the rest of it is all in C so it’s easy to modify the housekeeping code.

    The minor issue now is the 28 pin 328P doesn’t have enough I/O pins to do both 14 memory address lines *and* four row address lines for a character generator directly, so it’d be *either* character mode or full bitmap graphics, not both. (Still puzzling out the memory arbitration circuitry and how to switch between modes, but I think I may have a plan.) I could work around it with an external part to multiplex the top four address lines, or I could switch to the 40 pin 324. I’ll experiment with using a GAL because I need a switchable pixel clock divider to implement 256 pixel (32 column) mode anyway, might be able to do both on one part. But clearly next time I make a Digikey order I should get a few of the bigger chips to play with, that’d give me enough I/O lines to spare... maybe even enough to do tricks like hardware scrolling and multiple graphics pages.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •