twh/f2 Posted January 5, 2011 Share Posted January 5, 2011 http://wiki.strotmann.de/wiki/Wiki.jsp?page=ProjUSBCartAtariMouse the other question is, how the USB cart could be integrated if the Atari is already equipped with AtariMax SDX/MyIDE. In this scenario the cart port is taken and there would be no way to attach the USB cart. Maybe Carsten can say if an internal USB cart would be possible. grtx, \twh! Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 5, 2011 Author Share Posted January 5, 2011 (edited) The mouse in general is a concern, mainly because I only have one decent ST-compatible serial mouse (Logic 3 bought around 15 years ago and hardly used). I don't much fancy using a stock ST mouse (or "housebrick") if it breaks, and they seem to charge a premium for new ST-compatible mice on eBay. Edited January 5, 2011 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
Fox-1 / mnx Posted January 5, 2011 Share Posted January 5, 2011 the other question is, how the USB cart could be integrated if the Atari is already equipped with AtariMax SDX/MyIDE. Electrically, you can use the parallel-bus adapter which is used to connect a MIO (XL design) to an XE. It has space to mount a 2nd cartridge-connector. I guess both connectors are "wired" 1-on-1, not like the ones as the on-board Atari 800 (left/right cartridge). This doesn't solve any hardware incompatibility of course :-) Quote Link to comment Share on other sites More sharing options...
UNIXcoffee928 Posted January 5, 2011 Share Posted January 5, 2011 Why not start by just implementing the Trackball? Anyone who doesn't already have a trackball (for real Atari hardware) can pick one up easily and cheaply on ebay, and if it's coded for a trackball, a mouse will work fine for emulator users. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 5, 2011 Author Share Posted January 5, 2011 If the trackball code is similar to the mouse code, having switchable drivers will present zero problems. Quote Link to comment Share on other sites More sharing options...
atarixle Posted January 5, 2011 Share Posted January 5, 2011 Does Boss-X calculate the character widths on the fly? That's what my demo's doing at the moment. No, BOSS-PP-Fonts hold 128 bytes extra for the width of each character. If you start a writing new GUI, it made sense to make ISO-fonts with 256 Characters and 256 bytes for the width of each. Btw. in BOSS-X, the graphics-resolution is 320x192, the mouse-pointer-resolution is 160x96, the (if you can call it so) event-resolution is just 40x24. That's enough for handling buttons that are at least 8 pixels high. So if it's not a Graphics-8-Painting-Application, it's not necessary to have a mouse-resolution of full Gr.8. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 5, 2011 Author Share Posted January 5, 2011 (edited) ...BOSS-PP-Fonts hold 128 bytes extra for the width of each character. Good. This is what I indend to implement later. If you start a writing new GUI, it made sense to make ISO-fonts with 256 Characters and 256 bytes for the width of each. Thanks for reminding me! I'd almost forgotten that I wanted this as an absolute requirement from the ground up. We need to be clear about this before the font design work starts. ...in BOSS-X, the graphics-resolution is 320x192, the mouse-pointer-resolution is 160x96, the (if you can call it so) event-resolution is just 40x24. That's enough for handling buttons that are at least 8 pixels high. So if it's not a Graphics-8-Painting-Application, it's not necessary to have a mouse-resolution of full Gr.8. Although I insist on the fine granularity of the 320x192 mouse resolution, I've already decided to keep the viewport/window/menu rectangle resolution at byte boundaries. I can't yet say regarding vertical resoltion, since we'll be using fonts of indeterminate height. Of course, the 320 pixel horizontal resolution requires a 16-bit X coordinate register. I have already absorbed the pain of this. Edited January 5, 2011 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 6, 2011 Author Share Posted January 6, 2011 I've finished routines to hide and reveal as well as freeze and release the mouse pointer. Now, if the pointer is hidden when screen access is required (as it is in this demo), direct loads and stores are used. If the pointer is left visible, slower, masked screen access is used. Simply turning off the pointer when drawing the panel of a drop down menu, but leaving it on when reversing out the menu items should be a nice compromise between speed and aesthetics. It will be up to a given application or kernel routine whether mouse_hide is called before writing to the screen. The text rendering routine has also been updated to elminate 75% of the bit shifting (via use of tables). With external optimisations in the application's screen redraw, this should be fast enough to fill a text editor window (which in any case won't occupy the entire screen edge to edge). mouse3.xex Event handler and drop-down menus next. Quote Link to comment Share on other sites More sharing options...
+Philsan Posted January 9, 2011 Share Posted January 9, 2011 I've seen programs (f.e. Klony 2010) that support Atari ST AND Amiga mouses so I think only little things need to be changed to support an Amiga mouse too. Many Amiga mouses exists, they are better and... XL computers don't like grey ST mouses! EDIT http://www.atariage.com/forums/topic/141954-amiga-mouse-conversion/ Rybags: The Amiga pairs up 1-3 and 2-4 and the ST has 1-2 and 3-4 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 10, 2011 Author Share Posted January 10, 2011 You're right, Phil. The serial mouse I'm using is an aftermarket unit designed for the Amiga. I bought it in 1995 or so but only rewired it recently when I wanted to use it with an ST. Back in the day, however, I recall simply amending the 8-bit mouse driver to handle the Amiga pinout. So we can put a simple config option in for that. Haven't really got much of anything done this week, but the event handler and bitmap manipulation routines are taking shape. Just about got the menu bar on the screen... Quote Link to comment Share on other sites More sharing options...
+wood_jl Posted January 10, 2011 Share Posted January 10, 2011 I should think using a 130XE with a matching ST mouse would look very good, and be a very common solution. As there is no XL mouse, who cares....but sure would look right to have a matching Atari mouse where you can. Quote Link to comment Share on other sites More sharing options...
+Philsan Posted January 10, 2011 Share Posted January 10, 2011 Another solution could be Best Electronic's Best Trackball: http://www.best-electronics-ca.com/accesori.htm Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 10, 2011 Author Share Posted January 10, 2011 (edited) 2,000 lines into it and a menu should finally drop down tomorrow... I'm extremely glad Mr Fish designed this lovely font with 2 line descenders, otherwise the underlining would have looked crap. I noticed left padding in the lowercase "L" yesterday: I'm sure you put that in out of mischief, Paul! The font renderer will do bold and underline, and italics comes next. It's not geared up for anything larger than 8x8 cells yet, since I have no large fonts yet, and in any case I need to design a proper font file format for these proportional bitmaps (baseline offsets, economic use of memory for narrow characters, etc). Edited January 10, 2011 by flashjazzcat 6 Quote Link to comment Share on other sites More sharing options...
NRV Posted January 10, 2011 Share Posted January 10, 2011 2,000 lines into it and a menu should finally drop down tomorrow... Nice! Good luck with it.. I can imagine some applications running over that . Quote Link to comment Share on other sites More sharing options...
+Philsan Posted January 10, 2011 Share Posted January 10, 2011 A dream come true... Quote Link to comment Share on other sites More sharing options...
UNIXcoffee928 Posted January 10, 2011 Share Posted January 10, 2011 Can you explain how you will be designing the event handler, in technical terms? I have been thinking about how to implement some features from NLS/Augment on the Atari... particularly the Outline Processor, that allows a user to be able to create collapsible, hierarchical Outline-form Lists, within a document, in a text-editing program. These are sort of like modifiable drop-down menus that are created as you are typing, and activated by a mouse click. I've taken to re-watching "The Mother of All Demos" several times, now, and there are just so many great ideas in NLS, that never made it out of the Lab. All of the UI metaphors on the SDS 940 are things that an Atari 8-Bit could handle. Can you give the movie a watch? It may very well give you some great new ideas for "The Last Word", and this GUI. There were so many good ideas... I look at it & just go, "Wow, they had THIS in 1968?!?!", then say, "WHY don't we have this functionality NOW?". Quote Link to comment Share on other sites More sharing options...
+MrFish Posted January 11, 2011 Share Posted January 11, 2011 I noticed left padding in the lowercase "L" yesterday: I'm sure you put that in out of mischief, Paul! Yes, it's part of the American plot to distract and slow the "Europeans" down. Quote Link to comment Share on other sites More sharing options...
Bryan Posted January 11, 2011 Share Posted January 11, 2011 I've taken to re-watching "The Mother of All Demos" several times, now, and there are just so many great ideas in NLS, that never made it out of the Lab. Thanks for that link. Fascinating stuff. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 11, 2011 Author Share Posted January 11, 2011 (edited) I have been thinking about how to implement some features from NLS/Augment on the Atari... particularly the Outline Processor, that allows a user to be able to create collapsible, hierarchical Outline-form Lists, within a document, in a text-editing program. These are sort of like modifiable drop-down menus that are created as you are typing, and activated by a mouse click. I've taken to re-watching "The Mother of All Demos" several times, now, and there are just so many great ideas in NLS, that never made it out of the Lab. All of the UI metaphors on the SDS 940 are things that an Atari 8-Bit could handle. Can you give the movie a watch? It may very well give you some great new ideas for "The Last Word", and this GUI. There were so many good ideas... I look at it & just go, "Wow, they had THIS in 1968?!?!", then say, "WHY don't we have this functionality NOW?". Well, I came downstairs at 3am because my cough was keeping my wife awake and watched The 1968 Demo and I was quite dumbfounded. It really does make you wonder why it took another 25 years or more for many of these features to find their way into mainstream software (although it seems NLS/Augment's downfall was that it was rather difficult to learn). The outline processor is immediately impressive. I don't think Microsoft Word's outline view has all that functionality to this day. Absolutely amazing. I'm sure the Atari could handle some of this stuff. I seem to recall an outline and/or hyperlink text processor on the 8-bit; perhaps someone can remind me what it was. Anyway, thanks for bringing that demo to my attention. It's truly inspirational. If you come up with any good ideas for the outline processor, let me know. Perhaps I could offer some help with the text editing framework. Can you explain how you will be designing the event handler, in technical terms? Of course. Since I've been too sick with flu to do anything other than sit at the computer this past week, I've been cramming on GUI texts. A good resource is the Hitchhiker's Guide to GEOS found on this page. Since GEOS is a rather powerful (although limited) GUI implementation on a 6502, it made sense to me to try and steal some ideas. GEOS is superbly written and I think the API of the new Atari GUI will be similar to that of GEOS in many respects. Of course I also downloaded heaps of formal texts over the past few months, and more recently the source code of small-scale GUIs on the PC. Dan Winslow has also provided a lot of helpful guidelines, explanations and suggestions. Initially, I was going to gather events in the deferred VBI (just after rendering the mouse pointer in the same interrupt), and pipe them into a queue from which then event handler would then pull events in the main loop. However, simplicity being the watchword, I soon encountered difficulties in processing mouse clicks and user-input states from inside an interrupt, so I moved all the polling into the main-line event handler routine. I may augment this later when it comes to polling the keyboard, but it works well at the moment. Since the mouse sampling and pointer rendering all reliably happens every jiffy, the "get event" routine simply "blocks" and waits for mouse clicks/double-clicks/drags/menu-bar hovering in real-time. It then looks through the visible event regions for all the clickable objects on the screen, and calls the event routine for the relevant object. Mouse actions in other areas of the application workspace will be returned to the application. While the menu system is pretty straight forward, the next major job is coding up the "touch" areas for objects in a way that the event handler can search very quickly when something is clicked. Overlapping objects (may) need consideration, and the dialogue handler will probably require separate tables, since everything outside of the dialogue box will be out of bounds anyway. But the whole thing (such as it is at the moment) is really simple, and works pretty fast. To be honest, optimized raster graphics routines quick enough to work in real time seem more challenging than the event handler right now. The basics are already nailed down and are fast, but I won't know just how practical any of this is until I get a working text editor running which doesn't take five seconds to refresh the screen. Another challenge will be the dialogue handler, but fortunately I learned a lot from writing the text-mode GUI. Scroll-bars will be a pain when attached to drop-lists; they won't be seen as controls in themselves in that context, but simply as a means of returning a vertical offset (transparently) to the list control. Whether I'll run into trouble down the line with the simplistic event handler model, I don't know. If I have to change my mind later on and buffer all the mouse activity, it'll be a pain, but perfectly doable with a bit of thought. I noticed left padding in the lowercase "L" yesterday: I'm sure you put that in out of mischief, Paul! Yes, it's part of the American plot to distract and slow the "Europeans" down. It worked. I'd like to talk about a font format if you're into collaborating on one. I'd like to get the large font support built into the renderer as soon as possible, and while it's not a difficult task, I'll certainly need some fonts to test it with. Edited January 11, 2011 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 11, 2011 Author Share Posted January 11, 2011 Managed this today: It doesn't seem like much, but there are so many background "housekeeping" routines being written every step of the way, visible progress is slow. However, once all the ancilliary routines are written, things will speed up... 8 Quote Link to comment Share on other sites More sharing options...
MEtalGuy66 Posted January 11, 2011 Share Posted January 11, 2011 Wow.. looks like MacOS.. Quote Link to comment Share on other sites More sharing options...
spookt Posted January 11, 2011 Share Posted January 11, 2011 Jon you continue to amaze... Awesome! Quote Link to comment Share on other sites More sharing options...
Kylev Posted January 12, 2011 Share Posted January 12, 2011 flashjazzcat, I believe the outline processor you are thinking of might be The Creative Process by Antic Software. It was an outline producing program that allowed for multiple levels of indentation and automatic item numbering/lettering. I want to say that it also allowed for section collapsing, but I can't recall if that was with Creative Process or something later I used on the ST. Russ Quote Link to comment Share on other sites More sharing options...
atarixle Posted January 12, 2011 Share Posted January 12, 2011 Wow.. looks like MacOS.. Mac OS' menu-items never had underscores 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 12, 2011 Author Share Posted January 12, 2011 (edited) Thanks! As well as the underscores, provision has been made for right-justified shortcut key descriptions in the menu entries. A file menu entry might look like this in the definition block: .byte '&Save\Ctrl+S',0 "&" underscores the next character (as per Windows), while the backslash causes the remainder of the entry to be justified to the right edge of the menu. Doubling up the special characters causes them to be entered literally in the string. Actually the old System Mac font with wider verticals looks pretty nice; I might get Paul to design a clone of it. There will be certain restrictions placed on the size of the "system" font, but I see no reason why the font can't be user-selectable. I'll also put a drop shadow effect on the menus and make them recursive to allow for cascading. The wide left margin is to allow for checkmarks for those items which simply toggle some option. I'll upload a "playable" version in a day or so to allow for evaluation of menu responsiveness. I have to say that after running this on real hardware last night, I found myself still reaching for the mouse afterwards when I ran the FDISK program I wrote for MyIDE. I guess the two modes of interface operation (one for the PC and one for the Atari) has been momentarily blurred. I believe the outline processor you are thinking of might be The Creative Process by Antic Software. It was an outline producing program that allowed for multiple levels of indentation and automatic item numbering/lettering. I want to say that it also allowed for section collapsing, but I can't recall if that was with Creative Process or something later I used on the ST. That's the one, Russ. Thanks. I'll have to seek out a copy and play with it when I get a chance. Edited January 12, 2011 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.