Stefan Both Posted February 28, 2015 Share Posted February 28, 2015 (edited) Pheew! I did it somehow... Maybe I risked a damage, but hotplugging the Miide2 while trying to load the Workbook.atr did the job (hopefully it's still flashing. So it should be a good idea, to fix a cord on the key, before throwing it away. (To be able to get it back, if you recognise the door is closed - and it was THE key.) Stefan Edited February 28, 2015 by Stefan Both Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 28, 2015 Author Share Posted February 28, 2015 Agreed. Quote Link to comment Share on other sites More sharing options...
jk40001 Posted February 28, 2015 Share Posted February 28, 2015 Running now the GOS on real hardware from my SIDE2 and it is just amazing..thanks Jon!My only problem was I did not have ST mouse. If you guys also have only Amiga mouse like me, then you can turn it to st mouse simply by swaping yellow and brown wires. I just did it and it works fine:-) 3 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 28, 2015 Author Share Posted February 28, 2015 (edited) Great. For those who prefer not to mod the mouse, I'll upload Amiga-mouse friendly versions tomorrow. Will also add cart boot bypass so DOS can be booted instead, for the purpose of re-flashing. Edited February 28, 2015 by flashjazzcat 2 Quote Link to comment Share on other sites More sharing options...
w1k Posted March 1, 2015 Share Posted March 1, 2015 i cant wait for amiga mouse version Quote Link to comment Share on other sites More sharing options...
w1k Posted March 2, 2015 Share Posted March 2, 2015 hmmm? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 2, 2015 Author Share Posted March 2, 2015 "Hmmm" what? I'm not on the w1k developer payroll. 4 Quote Link to comment Share on other sites More sharing options...
w1k Posted March 2, 2015 Share Posted March 2, 2015 you wrote tommorow - today Quote Link to comment Share on other sites More sharing options...
Joey Z Posted March 2, 2015 Share Posted March 2, 2015 Possible, by splitting the frame buffer so that some of it is below the banking window and some is above it (already, the display list and screen RAM have 16KB separating them), but we have 200 lines already and I'm mindful of not ruining the NTSC display. maybe you could allow a slightly longer display for those with monitors (instead of TV's) that show all (or most) of the overscan to turn on optionally in the final version? unless that'd be too complex to handle multiple vertical resolutions. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 2, 2015 Author Share Posted March 2, 2015 It's not so much the issue of handling vertical resolutions as accommodating the frame buffer. If there's sufficient memory left below the banking window, it's no problem. Quote Link to comment Share on other sites More sharing options...
Muzz73 Posted March 2, 2015 Share Posted March 2, 2015 I got an adapter via ebay that switches the brown and yellow wires within. Universal switcheroo from ST to Amiga or vice-versa without having to open up the mouse. I think it came from somewhere in Europe and only cost about $8 USD. 2 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 3, 2015 Author Share Posted March 3, 2015 (edited) Here's an archive containing builds for both ST and Amiga mice: GOS ROMs.zip You can use the version of UFlash posted earlier in the thread to flash SIDE, SIDE2 and the 512KB Sic! cart. This version of the ROM permits a disk boot and drops straight back out of the cart if you boot with Option pressed, although I haven't tested this in all possible scenarios. It's a temporary fix for not being able to boot another flasher subsequently to reprogram the cart. Edited March 3, 2015 by flashjazzcat 2 Quote Link to comment Share on other sites More sharing options...
fibrewire Posted March 17, 2015 Share Posted March 17, 2015 Nice work FJC! Someday soon i hope to be back in the mix - don't you guys go getting all old on me Seriously, congradulations! Quote Link to comment Share on other sites More sharing options...
Frankie Posted March 24, 2015 Share Posted March 24, 2015 (edited) I flashed my SIDE2 and everything worked.. except my mouse. I have an Amiga mouse and it seems the only direction that works is down. I don't know if it's the mouse or something else.I made sure I flashed the correct version. Is there any other software I can use to see if my mouse is working normally? Frank UPDATE - Turns out my Amiga mouse is actually an ST mouse. I guess when I bought it I didn't notice it was one that had been modified to work on an ST. Edited March 24, 2015 by Frankie Quote Link to comment Share on other sites More sharing options...
+Philsan Posted July 29, 2015 Share Posted July 29, 2015 New GUI desktop! DESKTOP.XEX From Glucholazy Party 2015, G2F by Rocky/MadTeam. 7 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 29, 2015 Author Share Posted July 29, 2015 Looks pretty nice. Now where have I seen three colour hi-res before recently? 1 Quote Link to comment Share on other sites More sharing options...
+MrFish Posted July 29, 2015 Share Posted July 29, 2015 Yeah, I saw that too. Very nice, but not practical to implement. Here are the underlying P/M's. Yikes! 4 Quote Link to comment Share on other sites More sharing options...
+Philsan Posted July 29, 2015 Share Posted July 29, 2015 (edited) Yeah, I saw that too. Very nice, but not practical to implement. Here are the underlying P/M's. Yikes! New GUI Desktop.png Maybe Atari Logo only? Edited July 29, 2015 by Philsan Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 29, 2015 Author Share Posted July 29, 2015 The big PITA with PMG underlays (which I've used to similar effect recently with the new Ultimate BIOS) in the context of the GUI is the fact everything needs to be bound to character cells in order to get sufficient screen coverage, and I don't think even that would be sufficient for anything but a static image as we see in this demo. Having said that, I've liked the three luma effect since I accidentally stumbled into it while designing the icons for the BIOS. Funny this topic should be bumped, since I'm working on a rewrite (for the third time) of the GFX routines for the GUI. I figure this stuff has to be absolutely as fast as humanly possible before we start work on file systems and the like. 3 Quote Link to comment Share on other sites More sharing options...
analmux Posted July 29, 2015 Share Posted July 29, 2015 (edited) And another 128 colour GUI desktop. More than 10 yrs ago. "N" |-> "POS" => "liNux" |-> "liPOSux" Edited July 29, 2015 by analmux 2 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 29, 2015 Author Share Posted July 29, 2015 I think I prefer the grey one. 1 Quote Link to comment Share on other sites More sharing options...
popmilo Posted August 1, 2015 Share Posted August 1, 2015 Funny this topic should be bumped, since I'm working on a rewrite (for the third time) of the GFX routines for the GUI. I figure this stuff has to be absolutely as fast as humanly possible before we start work on file systems and the like.I thought they were already as fast as humanly possible ? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted August 1, 2015 Author Share Posted August 1, 2015 (edited) I thought they were already as fast as humanly possible ? It seemed so at the time, but some poor design decisions taken at the start of the project (i.e. using the "compressed window mask" clipping mechanism) resulted in code surviving which would have been better rewritten from scratch, so that's what's being done now. Even after the rectangle-based window manager was implemented, I stuck with the use of the look-up table to clip bitmaps. The LUT is a 256 byte array with binary 1s denoting visible pixels and binary 0s denoting off-screen/clipped pixels. All but the first 40 bytes of the array are permanently zeroed. Since objects can be drawn partly off-screen, a negative X offset will map to the permanently masked areas of the array. However, this design meant that the on-screen part of the LUT had to be computed prior to every render, since every object was drawn through the resulting mask. This wasn't an enormous overhead, but I could see (after stepping away from things for a while) that much of the time ANDing with the mask was a waste of cycles - as was populating it in the first place. Another problem is that using the LUT meant that the screen offsets were fixed to the start of the line (so that each column corresponded to a position in the mask array). This meant using counters or comparisons to test for the right-hand edge of a render, since we couldn't count up to zero, for example. In addition, the Y index register typically found three different uses inside a render: the screen line offset, the source bitmap offset, and the bit-shifting look-up table index. The theory is that this can be improved a lot. The clipping LUT has been done away with, and the first column, middle span, and last column of a bitmap are now handled by separate sections of code. This allows the centre (full bytes) span of a bitmap to be rendered in a very tight loop with no masking, comparisons, or counters. The source bitmap and screen pointers are dropped by the requisite amount to ensure that Y is always equal to 128 at the last column rendered (enabling quick detection of the final column by branching on the N flag). Y also serves as an index into the source bitmap and screen buffer using the same value. The low-level code has also been moved into RAM so that self-modifying instructions can be used to access the bit-shifting LUT using the X register. Finally, the bit-shifting LUT has been split into two tables: one containing only the bits rolled over to the right, and the other containing only the low bits rolled into the next byte. This removes two masking operations inside the loop. Bitmap clipping should also be significantly faster, since rather than iterating through off-screen data and bouncing it off the masking table, such off-screen data is now completely jumped over by adjusting the pointers, on both the horizontal and vertical planes. So, drawing a small centre section of a 320x200 pixel wallpaper bitmap should be magnitudes quicker than it used to be. Some of the most critical sections of code should run a fair bit faster, although much depends on getting the set-up code as optimal as possible. Here's a comparison of the old and new code which renders a character glyph of 8 pixels wide or less and which does not shift into an adjacent screen byte: ; old glyph render loop CharLineLoop1 lda linetable,x ; point SCR at beginning of line sta scr lda linetable+200,x sta scr+1 ldy tmp4 ; get data index lda (ptr1),y tay lda (shiftptr),y ; shift bits and lmask ; mask out high bits ldy xbyte ; get screen index and ForeGroundMask,y ; apply clipping mask ora (scr),y sta (scr),y inx inc tmp4 ; bump data dec tmp5 ; any more lines? bne CharLineLoop1 beq Done1 ; new glyph render loop ldy BitmapYStart clc ; pre-clear carry LineLoop lda (ptr1),y ; get byte tax lda ShiftTableLo,x ; shift bits (rolled over bits already stripped) ShiftLoAddr equ *-1 and FGMask ; apply clipping mask ora (scr),y sta (scr),y iny ; bump data dec LinesLeft ; any more lines? beq Done lda scr ; since index is bumped, add one less to screen pointer adc #39 ; carry already clear sta scr bcc LineLoop inc scr+1 clc bcc LineLoop Done rts The output of the bit-shift LUT no longer needs masking, and Y is not corrupted inside the loop (the latter is true of all the new render loops, even those spanning multiple bytes). A trick from the mouse pointer renderer has also been borrowed in this particular instance: bumping Y to iterate through the source bitmap, and bumping the screen pointer by one less to compensate. It's fairly heavy going changing everything, but it should all be easier to maintain and I'm expecting good performance. Edited August 1, 2015 by flashjazzcat 7 Quote Link to comment Share on other sites More sharing options...
popmilo Posted August 1, 2015 Share Posted August 1, 2015 Looks pretty good to me! I've always disliked horizontal byte order... So wrong for software sprites... Both Spectrum and Amstrad have modes like that and work with it very well using those 16bit register pairs... 6502 machines don't have that luxury. Only thing that I experimented with in that mode (more or less successful) is large block of unrolled code for each line on screen + small routine to init entry and exit point, jsr routine and then restore unrolled code operands on place of exit. Maybe something like this for Yreg = Xscreen (in bytes): lax (ptr1),y ; get byte lda ShiftTableLo,x ; shift bits (rolled over bits already stripped) and FGMask ; apply clipping mask ora scr0+0*40-0,y sta scr0+0*40-0,y iny lax (ptr1),y lda ShiftTableLo,x ; shift bits (rolled over bits already stripped) and FGMask ; apply clipping mask ora scr0+1*40-1,y sta scr0+1*40-1,y iny lax (ptr1),y lda ShiftTableLo,x ; shift bits (rolled over bits already stripped) and FGMask ; apply clipping mask ora scr0+2*40-2,y sta scr0+2*40-2,y iny .. . Setup FGMask and 'ptr1' to your shape top line, put rts instead of one of those 'iny' and then 'jsr' to beginning of one of these segments based on Y coord of top byte you want to draw.Each segments screen address is reduced by one to compensate Yreg increasing value. 14 bytes x 200 lines = 2800 bytes of unrolled code. You did say you wanted it to be as fast as possible ps. You can use LAX in your current code also instead of: lda (ptr1),y and tax. 2 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted August 1, 2015 Share Posted August 1, 2015 if you use the illegal opcode then it won't run on my 816 Quote Link to comment Share on other sites More sharing options...
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.