Laemeur

EDIT: My mistake! This was listed on eBay yesterday, so I shouldn't have posted it here. The auction is here, if anyone wants to take a look: http://www.ebay.com/itm/Commodore-CRT-Color-Monitor-Model-1702-/151791502068 Moderators, feel free to nuke this thread! I've got a working Commodore 1702 at my dad's place in Oregon City that I don't use anymore. I've moved to BC and I don't want to ship it up here, so if anyone in the Portland metro area is willing to pick it up, you can have it for $60. I got it some years back as part of a school auction, so it's got some masking tape on the top with instructions for loading files from BASIC and whatnot. I thought the tape added character, so I never took it off. Pictures attached.

Well, ain't it a small world. I read your "How Atari Made Me a Designer" article on the Hexanine site some days ago when I was initially on the trail of Cliff Spohn. I don't suppose you're aware of any sort of database that matches-up designers/illustrators with the their Atari work, are you? I've managed to identify a few of the artists I'm most interested in, but I'm still in the dark about whoever did the coin-op artwork for Asteroids Deluxe and Space Duel and other games.

I've found this out to be Steve Hendricks. Small gallery of his work here: http://www.highmarkdesigns.com/designerphotos.shtml, and some more drawings can be seen under the illustration link at FineLine Graphics.

Ah, I think I've solved it. That's "Kenyon", isn't it? On both the list videotwit provided and other lists of freelancers I've seen who worked for Atari, there's a "Steve Kenyon", but if you look at the art for Battlezone, it's the same surname signature as that Asteroids piece, only the initial is "C", not "S". I don't know where the name Steve came from, but I think it's actually Chris Kenyon that I'm looking at. Now, if only someone could tell me who the wiz behind the Space Duel coin-op art is!

Worthfull enough to be resurrected twice, I say. I was admiring the artwork for the 8-bit computer version of Asteroids the other day, and I'm darned curious about who the painter is. On the linked image the signature is almost legible. Looks like "chris K burger" or maybe that's "sugar", or ...something -- but Googling around is proving fruitless. Anyone know the artist, or have a better guess at the name?

It is an ingot power supply, as a matter of fact. Yep, you guys were right -- I just put the Atari on a different power supply and it looks great. Thanks for your help!

The audio's still good for now, actually. I suspected the power supply would come up, but I don't have a spare to test with.

Hello, folks. I was out of the country for a few months, came back and switched-on my Atari and during its period of neglect it seems to have developed a rolling black-bar video problem. I've put a video up on YouTube . And here's a still: After I switch it on, as you can see in the video, it sometimes almost looks okay for a few seconds, but then the colour changes and the bar gets really intense. The computer is an NTSC 800XL. The problem is definitely on the computer, as the monitor behaves perfectly with other sources. Anybody familiar with this and know what components I need to look at to get it righted? Thanks for taking the time to look.

Well, the clothesdrier patent was issued in 1980 (filed in '77) and Atari printed those serial number tags in, what, 1983 or later? They should have known the number was invalid by then. I should note that the clothesdrier patent number does not appear on all XL tags, so the situation was eventually corrected, but it did appear on three tags which were posted in the other thread. I just thought it was an amusing error.

So I was looking for patent drawings for the XL series computers, but wasn't finding any and I thought perhaps the USPTO just had some holes in their online database regarding assignee information or something. I thought if I could just pull the patent numbers off of an XL and look them up, I'd be sure to find them. I remembered a thread on AA with pictures of serial number tags, so I dug that up and got just what I was looking for, from the likes of hunmanik and pepax: The first two design patent numbers reference our old friend, the CX40 joystick, but... something's not quite right here. Take a look at that last patent number, D255,315. Then take a look at what that patent number is for :

That looks excellent. I wish there were patent drawings of the XL systems, but as far as I can tell, design patents were never issued for them, so some other source needs to be found for those.

Wow. Excellent thread, thanks for bumping it. I was totally unaware that there were these variations, I just assumed type-4 was it. I'm going to have to keep my eyes open for a parts XL with a different keyboard since my type-4 has been a constant pain in the butt.

How about patent drawings?

Darn! Thanks for checking that out, I really appreciate it. Now I know it's something I have to address. Yeah, I knew about that. That's just me being lazy and not checking variables in a few places. It'll get fixed, I swear.

You just want to have your Atari draw itself on a Tek 4014, don't you?

It's sort-of a joke. As it is, the program's just a proportional font demo with no load/save functions, and bad buffer handling. It's just barely more useful than Memo Pad, though, so I figured I'd be a smartass and call it Memo Pad Pro. That won't be its name when it's actually useful. I've noticed that, too. Can somebody verify that on real hardware? I'm pulling the key data right off of POKEY, so it's not being altered by the OS key handler routine. I suspect this is an emulation or PC problem, but if it's not, hopefully I can come up with a way around it. Not in Memo Pad Pro. In what I'm turning it into, yes. .Blame your Atari. It's just cycling through the 16 hues in the hardware.

Haha. I must have caught this through telepathic transmission, because at the same time you were writing this it dawned on me what you meant in your previous post. It is an elegant solution, and it is the one I'm going to use. Thanks for sharing. Unfortunately, last night when I hadn't quite caught your meaning yet, I spent a few hours hacking away at an incredibly convoluted linked-page buffer system which I shall now quite happily abandon in favor of your much simpler approach. I keep finding little ways to make it faster. Last night I got it up to about 1250 characters/sec, which is a skosh faster than what a VT52 terminal can get over its serial line, so I think I'm doing okay I'm also using a list of initial-character addresses for each line, but then I just mark entire lines for redraw rather than individual characters. There's a trick, though, to ensure immediacy of feedback for the user. This is my current priority-order after a buffer-altering keystroke: 1 | Characters are inserted/deleted from the buffer. 2 | If a printing character was keyed, it is drawn immediately to the screen at the caret's current position. Because of this, the user can type faster than the line-drawing routine and still see their letters appear on the screen instantly. 3 | Starting from the first character at the top-left corner of the screen, line-breaks and caret position are calculated for the whole display, and the list of initial characters is updated. This calculation stops when it reaches the last visible line, or, if the caret has left the screen, once the caret has been found. 4 | Key-click is sounded to let the user know that the important consequences of their action have been handled. 5 | Caret is redrawn 6 | Interruptable line/screen redraw subroutine is called. 2 & 3 are really the key, I think. Having an up-to-date location for where the next character goes allows you to operate, more or less, like a mechanical typewriter, and just bash out one character at a time. The line/screen redraw is only really used to clean-up the mess that the typewriter-style drawing creates.

Yes, the A8 in 1979 was superior to the ST in 1985. Or something like that.

Here's an .atr version with the hiccuping keyboard and the too-frequent screen updates fixed: http://drop.io/MPP_ATR That's way beyond my knowledge level right now Yeah, that's absolutely on my to-do list for the actual editor, although I'm still trying to puzzle out how to actually implement it. It's nothing sophisticated at all. Right now the line-drawing routine starts at the current line and draws to the bottom of the screen, but it checks a flag when it's first called to see if it should start from the top line because the screen's been 'broken'. There are a few circumstances where that flag is set, and early-on my highly convoluted program-flow had it getting cleared before it should have. My incredibly crufty solution at the time was to have it get incremented/decremented rather than set/cleared so that requests for redraw could queue up. I'm back to setting/clearing now that I've got things happening in more or less proper order. For a while I was trying to work out clever ways of 'marking' areas of the screen that needed updating, to save character-drawing cycles, but I eventually got the character drawing fast enough so that drawing a whole screen wasn't such an abhorrent time-suck anymore. Still, I would like to work on clever ways of avoiding redraws when not necessary, but I don't have any really useful information to that effect right now.

I want to try and put together a sort-of simplified Swyft/Canon Cat type editor with navigation via "Leap"s, inline calculation, outline editing, and some other things. Proper cut/paste, disk I/O, and handling of large files are my immediate priorities, though. Thanks! I have a few bugs in there, still! I'm not catching keystrokes properly apparently because there's some kind of timing issue when the edit buffer is too small and you're at the beginning of a line. Also, you'll start to lose keystrokes as you insert text in front of larger and larger buffers. And I have another bug in there where requests for a full redraw of the screen are piling-up when they're not supposed to. The good news is that all of these are fixable, and will be fixed. I just sorta bashed this out to see if I could.

Yeah, I know, the last thing in the world anybody needed was an updated version of Memo Pad, but this is sort-of a research project. I wanted to see proportionally-spaced text on the Atari, so took a shot at a simple implementation before beginning work on a more ambitious program. My real Atari is in a box 450 miles northwest of here, so I can only verify that this works okay in Atari800Win, both in OS-B and XL/XE modes. I spent a couple nights just trying to get the character drawing as fast as possible, and I think I did pretty good, though I can still probably shave a few cycles off somewhere. No disk I/O, but it should print alright, which is almost as good with an emulator or an SIO2PC setup. Anyway, screen shot is attached for your viewing pleasure, and here's a link to the .xex file: http://drop.io/memo_pad_pro_9bk

It's funny to have to really think about this stuff when text-editing on modern hardware seems so ubiquitous and instantaneous. It's a very fun programming challenge. Thanks a lot for your insight.

I actually just started wrestling with this exact same problem a few nights ago as my first proper Atari assembly coding project. Here is a disk image with a very, very crude proportional font demo. Binary load TEST.65O from DOS, then run at address $3F33. When you type forward, only the last character is blitted, but when you backspace, the whole screen is redrawn. Once you get a few lines down the screen, the redraw gets agonizingly slow.

I think maybe this .tek file is more suitable for our testing purposes. zing.zip

In case you haven't played with it already, I fired-up xterm in Tek mode (the off-the-shelf Cygwin build does have Tek support compiled-in), and it does indeed behave just like a storage-tube terminal. If you mis-type a shell command and backspace over it, the cursor moves but the characters are not erased, so when you type over them, it draws each glyph right on top of the old one. You have to send a PAGE command to clear the screen. And when shell output reaches the bottom of the display window, it starts again from the top, just drawing right over what's already there. I haven't dug into it enough to get any graphics drawn, but if you resize the Tek display window, it DOES do a bit of dynamic resizing, at least with text. It's a little strange, the glyphs don't change size, but they do change location. It'll be interesting to see how graphics are treated.