_The Doctor__ Posted November 5, 2014 Share Posted November 5, 2014 https://github.com/EtchedPixels/FUZIX Getting straight to the meat of this sandwitch.... This looks super promising! Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 5, 2014 Author Share Posted November 5, 2014 @flashjazzcat: Have you seen this? https://plus.google.com/+AlanCoxLinux/posts/a2jAP7Pz1gj It's a post on Fuzix by Alan Cox, a kind of unix for 8-bit systems that runs in as little as 32K ram/32K rom. Thanks - someone else put me onto that the other day. It's written in C and doesn't have a GUI. Interesting, but Lunix is similar and written in assembler and also 'Unix-like'. Fuzix appears to score with banked memory support, which of course we already have. I'm quite interested in studying the file system, though. 1 Quote Link to comment Share on other sites More sharing options...
Chilly Willy Posted November 6, 2014 Share Posted November 6, 2014 Thanks - someone else put me onto that the other day. It's written in C and doesn't have a GUI. That was my thought... it doesn't have a GUI, and here you have a GUI. Interesting, but Lunix is similar and written in assembler and also 'Unix-like'. Fuzix appears to score with banked memory support, which of course we already have. I'm quite interested in studying the file system, though. It's always good to look over things like this. Even if you can't use it, you may get ideas on making your own stuff better. Quote Link to comment Share on other sites More sharing options...
Prodatron Posted November 6, 2014 Share Posted November 6, 2014 They already had a discussion about an A8 port here at https://plus.google.com/+AlanCoxLinux/posts/a2jAP7Pz1gj Kevin Ogden04.11.2014How hard would porting the 6502 code to the Atari 8-bit be? I have an 800XL w/ 64K base RAM and 512K extended in 16K banks LOL?Alan Cox04.11.2014+Kevin Ogden not an off the shelf 800XL then - can you map banks into any of the 64K range ??Kevin Ogden04.11.2014+Alan Cox With most Atari 8-bit RAM upgrades, 16K extended banks get mapped into $4000 to $7FFF. Same scheme as the Atari 130XE which made it the defacto standard. PORTB is used on the PIA for bankswitching. Upgrades from 128K to 1MB are pretty easy to pull off on the 600XL/800XL and XE series. Most common are 256K extensions which yield a total of 320K RAM. Upgraded Atari machines are far more common that folks with REU's for their C64. My upgrade board gives me a total of 576K and has several switchable modes for things like supporting ANTIC banking, etc. I also have a PBI bus IDE controller that is well integrated with ROM OS.?Alan Cox05.11.2014+Kevin Ogden so no way to bank zero page and stack or to get 32K of banked space - I don't think it's going to work that well then. You'd have to copy chunks around same as you would with a C64 REU. Single user might work but I imagine anything running in the background and it would suck rocks.? Kevin Ogden05.11.2014+Alan Cox A RAM expansion could be built that does 32K banks but it would be "non-standard" and not supported by the existing software that can use extended RAM. Someone is working on a full GUI-based OS using the standard banking scheme. Even does preemptive multitasking. He's making good progress so far. Also remember the A8 has a 70%+ clock speed advantage over C64 so it wouldn't be quite as painful but I see your point, it would be a bit messy.? Fuzix requires 32K mapping (like Uzix already did) to run in a good way, so that will be an issue for the A8. Currently he is working on the MSX version. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 6, 2014 Author Share Posted November 6, 2014 (edited) That was my thought... it doesn't have a GUI, and here you have a GUI. Yes, but I also have a kernel which I spent the past six months or so writing in assembler. I'll be far more inclined to think about porting the GUI to another OS when I'm not so preoccupied with getting the thing running on the original target system. FUZIX isn't the first small 8-bit Unix-like implementation (it simply appears to be the most current and potentially more useful than others because of its ability to use extended RAM), and Lunix and Geck/OS are already written and working, and coded in assembler. It's always good to look over things like this. Even if you can't use it, you may get ideas on making your own stuff better. I agree, and that's why I already studied Unix architecture, the Minix book, Geck/OS, LNG, and why I rewrote the entire system as an approximate re-implementation of SymbOS. As said: there's doubtless great stuff to study here, but what's holding this project up is not a lack of ideas but the time it takes a single pair of hands to write assembly language. If I had written the A8 GUI/OS in C, it would probably be approaching completion already, unless the size of the object code generated by CC65 had already caused me to throw in the towel. As Prodatron says above: the A8 has especially limiting RAM banking, and a CPU not well suited to running C compiler generated code. Believe me, my head is heavy with derived ideas. Edited November 6, 2014 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted November 6, 2014 Share Posted November 6, 2014 (edited) Yes fine young GUI coder, back into the dungeon now... you are wasting precious cycles... typing this gibberish and interacting with the fleshy meatbags made of mostly water! You must code now... code now.... code..... | Food, water, code... repeat..... until passed out..... Where are those jolting energy drinks hiding? Edited November 6, 2014 by _The Doctor__ 1 Quote Link to comment Share on other sites More sharing options...
576XE Posted November 6, 2014 Share Posted November 6, 2014 And when he may take asleeeeeeeep? 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 6, 2014 Author Share Posted November 6, 2014 I'm teaching myself Java at the moment and brushing up on my C... gotta put food on the table. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 1, 2014 Author Share Posted December 1, 2014 (edited) A little intermediate update while I work on getting something downloadable completed before Christmas. For a while the fact the software blitter worked on byte boundaries had been bugging me. The blitter is used to move the front window place to place when it's fully visible, and it'll soon be used to blit the partially visible area of an off-screen window too (only the newly revealed area being redrawn). But it'll also be used to help scroll list boxes, consoles, text editor windows, and other scrollable content too. So last Thursday I decided to alleviate the byte-bound limitation and write a new blitter which works at the bit level. I expected this to take a day or two, but I only got the bugs out of it today. The reasons for this turned out to be manifold (bugs in other places, for one), but now the thing works properly it's really freed things up. Windows don't have to be on byte boundaries any more... indeed, nothing does. I did a bit of searching around the Net prior to writing the new blitter, but I couldn't find anything pre-written. It's quite an interesting undertaking in its own right. Aside from the normal positional considerations which dictate the direction of the copy (top to bottom, bottom to top, left to right, right to left), the pixel-precise blitter also has to account for the differential in bit offset between the source and destination copy, and approach the line copy accordingly. The bit rotation is accomplished using the 2KB look-up-table (with left shifts accomplished by moving right 8-n places), but one or two teething problems took me several hours to fix. Vertical copies at the same x-coordinate are of course especially fast (since no shifting is required), and this is what we'll use for scrolling up and down in multi-line text controls. Edited December 1, 2014 by flashjazzcat 14 Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted December 2, 2014 Share Posted December 2, 2014 (edited) I did a bit of searching around the Net prior to writing the new blitter, but I couldn't find anything pre-written. http://www.atarimania.com/mags/pdf/Atari-Magazin-89-05.pdf (Real)-Page 52 Edit: Works via separate buffer and not screen-to-screen. Edited December 2, 2014 by Irgendwer 3 Quote Link to comment Share on other sites More sharing options...
Prodatron Posted December 2, 2014 Share Posted December 2, 2014 Now even pixel based, very cool!! I like the concept to have an universal blitter routine! Now you brought me to the fantastic idea of scrolling the content of a background window, when this is overlapped by several other windows! This is currently not possible in SymbOS, but I just recognized that it's so simple, when you already have the dirty-rectangle algorithm. It will just be used for doing several mini-scrolls in the sub-rectangles. 4 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 2, 2014 Author Share Posted December 2, 2014 (edited) Now you brought me to the fantastic idea of scrolling the content of a background window, when this is overlapped by several other windows! This is currently not possible in SymbOS, but I just recognized that it's so simple, when you already have the dirty-rectangle algorithm. It will just be used for doing several mini-scrolls in the sub-rectangles. That's plain spooky. I had exactly the same thought last night about twenty minutes after I made the video. The console will look really cool scrolling a directory listing when behind other windows! I had previously intended to just do full redraw once the prompt reappeared if the console was partially obscured, but scrolling the sub-rectangles will be far preferable. http://www.atarimania.com/mags/pdf/Atari-Magazin-89-05.pdf (Real)-Page 52 Edit: Works via separate buffer and not screen-to-screen. Thanks nevertheless for taking the trouble to dig that out. It looks pretty long-winded, and isn't screen-to-screen as you say. The most complicated part of my routine is the code which sets up all the offsets, clipping masks, etc. Thereafter, the loops are pretty simple: // // Copy Blitted line data from left to right (when dest < source) // And destination pixel offset is lower than the source pixel offset // .local BlitLineFromStart ldy #0 sty tmp1 lda (ptr1),y and SourceMask,y tay lda (ShiftPtr),y and RMask sta tmp3 ldx tmp5 Loop1 ldy tmp1 iny lda (ptr1),y ; get source data and SourceMask,y ; mask out background (SourceMask is a foreground mask) tay lda (ShiftPtr),y ; get shifted bits pha ; store for later and LMask ; get leftmost bits ora tmp3 sta tmp2 ldy tmp1 lda (ptr2),y ; get byte at destination and DestMask,y ; mask out foreground (DestMask is a background mask) ora tmp2 ; OR in bits sta (ptr2),y pla and RMask sta tmp3 inc tmp1 dex bpl Loop1 rts .endl There are six routines to handle the different shifting/directional combinations (two are fast "no shift" copies). I think the 2KB right-shift LUT has proved the most useful thing of all with regard to graphics. Edited December 2, 2014 by flashjazzcat 3 Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted December 2, 2014 Share Posted December 2, 2014 ... and SourceMask,y ; mask out background (SourceMask is a foreground mask) tay lda (ShiftPtr),y ; get shifted bits pha ; store for later and LMask ; get leftmost bits ora tmp3 sta tmp2 ldy tmp1 lda (ptr2),y ; get byte at destination and DestMask,y ; mask out foreground (DestMask is a background mask) ora tmp2 ; OR in bits sta (ptr2),y pla and RMask sta tmp3 ... --> ... and SourceMask,y ; mask out background (SourceMask is a foreground mask) tay lda (ShiftPtr),y ; get shifted bits tay ; store for later and LMask ; get leftmost bits ora tmp3 sta tmp2 tya and RMask sta tmp3 ldy tmp1 lda (ptr2),y ; get byte at destination and DestMask,y ; mask out foreground (DestMask is a background mask) ora tmp2 ; OR in bits sta (ptr2),y ... I try to avoid PHA/PLA, they are slow and not really needed in non-concurrent cases. 4 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 2, 2014 Author Share Posted December 2, 2014 --> ... and SourceMask,y ; mask out background (SourceMask is a foreground mask) tay lda (ShiftPtr),y ; get shifted bits tay ; store for later and LMask ; get leftmost bits ora tmp3 sta tmp2 tya and RMask sta tmp3 ldy tmp1 lda (ptr2),y ; get byte at destination and DestMask,y ; mask out foreground (DestMask is a background mask) ora tmp2 ; OR in bits sta (ptr2),y ... I try to avoid PHA/PLA, they are slow and not really needed in non-concurrent cases. Nice touch - thanks! Quote Link to comment Share on other sites More sharing options...
bfollett Posted December 6, 2014 Share Posted December 6, 2014 Gee, I noticed that this thread is 5 year old today! I didn't know if you were into traditional or modern gifting so here's both. 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 7, 2014 Author Share Posted December 7, 2014 (edited) Thanks! And it's just a little over six years since I joined this forum too. Here's to another six years of productivity! BTW: there's a yellow button on my website intended for those readers genuinely interested in modern gifting. Edited December 7, 2014 by flashjazzcat 5 Quote Link to comment Share on other sites More sharing options...
fujidude Posted December 8, 2014 Share Posted December 8, 2014 (edited) Deleted, thread too old for my comments to be of proper value. Sorry, Im new around here. Pleased to "meet" you all by the way. Edited December 8, 2014 by fujidude Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 8, 2014 Author Share Posted December 8, 2014 (edited) Welcome! What was the original comment? "Nice new thread!"? Not sure if this one would fit the bill: http://atariage.com/forums/topic/231161-atari-8-bit-which-gui/ It's only six weeks old. Edited December 8, 2014 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
fujidude Posted December 9, 2014 Share Posted December 9, 2014 Welcome! What was the original comment? "Nice new thread!"? Hi and thanks for the welcome. I responded to the OP and gave my opinion on trying to make a GUI for the A8. To summarize, I said that for my mileage, no need to bother, but if it is a personal passion or challenge, go for it. I can be much more productive on modern systems. It is the nostalgia of doing the old things that I value most about the A8 now. That's just my feedback. Obviously, time has passed and it has been started, so there no point in saying not to bother now. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 9, 2014 Author Share Posted December 9, 2014 OK - thanks. I appreciate that point of view, but as you observe, the project is well advanced now. Of only all commentators shared your succinctness. 3 Quote Link to comment Share on other sites More sharing options...
Roydea6 Posted December 11, 2014 Share Posted December 11, 2014 OK - thanks. I appreciate that point of view, but as you observe, the project is well advanced now. Of only all commentators shared your succinctness. Hi Is this still going to fit into the GUI bank of the ultimate and is there a key press or screen selection to activate it. While I am waiting for the GUI I am wondering if I could use this bank for something else in the meantime (like) an older SDX121 or other 64k rom.... Regards, Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 11, 2014 Author Share Posted December 11, 2014 (edited) Is this still going to fit into the GUI bank of the ultimate and is there a key press or screen selection to activate it. While I am waiting for the GUI I am wondering if I could use this bank for something else in the meantime (like) an older SDX121 or other 64k rom.... It should still fit into the 64KB slot, but there's currently no way to make that slot bootable. Candle assures me there will be at some point in the future. Since the first bank of that 64KB block is never present on powerup, I'm not sure what else you could do with it, but if you can figure something out, go for it. I'll probably test by replacing SDX with the GUI in the meantime: that's bootable and offers plenty of space for the ROM disk. Edited December 11, 2014 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 13, 2014 Author Share Posted December 13, 2014 List control with column headings is nearly done: Content will be sortable in ascending/descending order on any column (click header, as per Windows). Here the list is sorted on process name. This is one of the more complicated UI controls, so I'll be pleased to get it out of the way. 11 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 14, 2014 Author Share Posted December 14, 2014 This is the list sorting in action. It's a little unclear in the video, but I'm clicking the column headers to sort columns or reverse the sort order if the list is already sorted on said column. The list also updates periodically anyway, and it would be nice to set the delay to the next automatic update from the time of the last click. In addition, the whole list control is currently redrawn by the periodic refresh, when just the content (not the header) should redraw. Anyway: it's gradually getting there; just the scroll bar and list clicks to sort out, plus a few more bugs to iron out and then I'll release it. Obviously some of the things I wanted to put in will have to be left out because they just won't be completed within the next fortnight. 9 Quote Link to comment Share on other sites More sharing options...
Chilly Willy Posted December 14, 2014 Share Posted December 14, 2014 It's amazing how fast this is. You've really got some efficient code going there. 2 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.