Laemeur
-
Content Count
76 -
Joined
-
Last visited
Posts posted by Laemeur
-
-
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.
-
...
The only other leads I got was from page 2 of the Missle Command Instruction booklet. There is a small illustration with a signature. The first name is Steve but I can not quite make out the last name. (Handrick,Handrich,Hendrich,etc...) I checked out numerous spellings online but to no avail.
-Chris
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.
-
If someone can post links to blueprints of the systems, ideally straight-on top/front/side drawings, I would create at least a few.
How about patent drawings?
-
1
-
-
on my stock 800XL it doesnt work... keys AJLZXCVB all dont search with shift+control+X, and dont make that 'crunch' sound when a key is hit...
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.also when you hold down enter for many lines the char set gets corrupted and all chars show as garbage, even EOL...sloopy.
That's just me being lazy and not checking variables in a few places. It'll get fixed, I swear.
-
Does anyone have any .DXF (or other 3D) data files representing Atari equipment?
If you have any (regardless of format), or would like to make some to share with the world, this is a good place to put them.
You just want to have your Atari draw itself on a Tek 4014, don't you?
-
memopad pro is probably not a good name for this project since its not a replacement for the firmware based memopad.
What it is, is the beginnings of an editor or a word processor.
Just my opinion.
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 have noticed that CONTROL+SHIFT+ letter doesn't jump to several of the Alphabets (i.e.) A, B, and C for sure posibly more.
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.
Is there ever going to be a LOAD feature.Not in Memo Pad Pro. In what I'm turning it into, yes.
.I have tried getting different COLORS, but have not cycled to anything better than the original..
Blame your Atari.
It's just cycling through the 16 hues in the hardware. -
Pretty easy, and quite elegant. Set up two pointers in page zero: I call them POS and LINK. POS is simply the "address" of the cursor position. LINK is the address of the text stored at the top of the buffer, beyond the empty space ahead of the cursor. When a file is first loaded, it's moved to the top of the buffer. POS points to the bottom of the buffer, while LINK points to the first character after the empty space.
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.
The character draw routine must be really fast. In The Last Word, I keep a map of all the characters on the screen and any that haven't changed don't get redrawn on the next refresh. On top of that, I keep a table of the start address in memory of each line on the screen, and for each address which hasn't altered on the next redraw, even comparisons with the screen map are skipped for that line. Only the current and "previous" lines are redrawn at all times.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.
-
looks like a starting version of emacs... you have a atr or exe to try on my real atari?
Here's an .atr version with the hiccuping keyboard and the too-frequent screen updates fixed: http://drop.io/MPP_ATR
I've been trying to figure out ways to create virtual memory pools using extended banks of RAM in order to edit extremely large files (32K, 48K, etc). There are lots of overheads, though, and it gets complex and slow very quickly when you're dealing in terms of a text editor. You'll be onto a winner if you can crack something like that.
That's way beyond my knowledge level right now
I would strongly advise the use of a non-linear text buffer, a la The Last Word. Arrange your text so the free space is always in front of the cursor. Text behind the cursor is moved to the low end of the buffer, pulled from the top of the buffer as you move through it and vice versa. Editing will be super-fast regardless of file size.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.
"Requests for a full redraw" is interesting. Do you have some kind of queueing system? I'm currently trying to work out how to implement a full-scale word processor using proportional fonts, so if you have any cycle-saving ideas to share, I'd be most appreciative!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.I'd like to see this as well. Any homebrew is a good one! Yours looks nice. What are some of the 'extended' features going to be included in the more ambitious program? Cause that one is pretty impressive. I'd run it on real hardware for real.
Thanks!I like this: it's really fast, too. Looking forward to seeing more features added to the program.
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.one thing though
as i type, some keys presses are missed, and it seems that every keypress screen refresh is taking place - if its nessesary or not - this would greatly improove the speed it operates
-
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.
Looking good so far. The problems really come when you implement word wrap, etc. The way The Last Word is implemented (as of version 3.1), there are three distinct levels of optimisation:
1. At the bitmapping level, a character is only mapped to the screen if the relevant character isn't already there. This saves about 80% of bit mapping during everyday editing operations. This optimisation is implemented inside the put character routine so isn't simply confined to the editor's screen refresh.
2. Scrolling is done with a dynamic display list rather than block moves. This interacts quite neatly with (1) because of a list of pointers to the character maps for each line of the screen which are rotated up or down along with the LMS pointers in the DL.
3. A list of line lengths and line addresses (in the text buffer) is maintained and following an initial "full" redraw, the refresh routine checks these tables and skips anything which hasn't changed. At the minimum, only the current line is updated everytime a key is pressed. This is why there's a slowdown if a line wraps at the top of a long paragraph: all the text below reshuffles itself, triggering redraws for every line.
Current experiments have me totally convinced that incomplete screen redraws will be essential in a WYSIWYG word processor on the 8 bit. There are few drawbacks, since you only have to let up typing for a couple of seconds and the screen will properly update while the program is idle. I think it's worth putting into LW (3.11?) as it stands, because of the speed boost. I may actually junk (3) above and save cycles with some in-line code when implementing the interruptable screen refresh, since the complications of using this along with a line table which may or may not get a chance to update between keystrokes are immense.
-
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.
-
1
-
-
-
Since the vector output is sent to a raster display via xterm, I don't know if the "Storage Tube" aspect of the Tektronix is emulated faithfully, with respect to how the actual terminal hardware leaves the lines on the display, once they have been rendered. I would guess that it is, though, because it seems like a fairly intrinsic aspect of the Tektronix display method. Should be... won't really know until it's tested, though.
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.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
FS: Commodore 1702 monitor for pickup in Portland metro
in Buy, Sell, and Trade
Posted · Edited by 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.