Casey Posted May 14, 2017 Share Posted May 14, 2017 Did you do the steps in order? If you did, there is legible text with instructions on how to proceed through the program. If you didn't, there are flashing characters and random symbols all over the bottom of the screen. Quote Link to comment Share on other sites More sharing options...
2600problems Posted May 15, 2017 Share Posted May 15, 2017 well, I've got the second one, even though I followed through. am I using an inferior version of prodos, do I have to go through basic? what do I need to do? Quote Link to comment Share on other sites More sharing options...
Iamgroot Posted May 15, 2017 Share Posted May 15, 2017 The program should work fine with or without DOS. The dbl-hi-res screen views random graphics for page 1 or a picture if one was previously loaded and random graphics for screen #2. The four lines at the bottom of the screen should tell you which dbl-hi-res screen you are viewing, and while viewing screen #2 you will see text on text page #2. While viewing screen#2 the program then clears screen #1 to all white, then switches to view screen #1 and text page #1. I didn't get too extravagant with the graphics as the program was getting long enough. When booting up, make sure the FLASH command is not invoked at any time. If you have a startup program, rename it to something else temporarily and let it boot straight to the applesoft prompt. Then follow the directions given earlier. Quote Link to comment Share on other sites More sharing options...
sarkeizen Posted July 26, 2017 Share Posted July 26, 2017 New post: Double hi-res from the ground up part 8. https://lastrationalman.blogspot.ca/2017/05/apple-ii-double-hi-res-from-ground-up_11.html 1 Quote Link to comment Share on other sites More sharing options...
sarkeizen Posted August 21, 2017 Share Posted August 21, 2017 Part Nine - is now up, where I tie everything together with a nice API -- as an added bonus I show off my (lack of) artistic talent! I've also started using the domain http://battlestations.zone - all the old links to my previous (and somewhat pretentious) domain http://lastrationalman.blogspot.com will get redirected. 2 Quote Link to comment Share on other sites More sharing options...
Jackel192 Posted September 5, 2017 Share Posted September 5, 2017 works perfect. do you know any other MC programs Quote Link to comment Share on other sites More sharing options...
thorr Posted September 22, 2017 Share Posted September 22, 2017 Part Nine - is now up, where I tie everything together with a nice API -- as an added bonus I show off my (lack of) artistic talent! I've also started using the domain http://battlestations.zone - all the old links to my previous (and somewhat pretentious) domain http://lastrationalman.blogspot.com will get redirected. Thanks! Your articles are awesome and I am really looking forward to the future articles. Please keep them coming! I am really looking forward to seeing how to handle animated objects moving on a background. 1 Quote Link to comment Share on other sites More sharing options...
Michaelangel007 Posted October 26, 2017 Share Posted October 26, 2017 This deficiency about not being able to examine/change a DHGR screen at the bit level has been addressed. Please see my DHGR.BYTE program. https://github.com/Michaelangel007/apple2_hgrbyte Examples, and full assembly source is included. Michael AppleWin Developer Oh what about sprite tools! Speaking of DHR drawing programs, there are only two I know of for the Apple II - 816 Paint and Dazzle Draw. I use them both. Often I draw a sprite sheet using Dazzle Draw then write a BASIC program to load it and get it into the format I want and save it as a binary file. One annoying thing is that neither of these programs lets you manipulate individual bits. Quote Link to comment Share on other sites More sharing options...
whiteplanet Posted December 11, 2017 Author Share Posted December 11, 2017 I take it that there are no more tutorials. Quote Link to comment Share on other sites More sharing options...
sarkeizen Posted June 25, 2018 Share Posted June 25, 2018 I take it that there are no more tutorials. I apologize. Things have been busy for me for a while now. I do have some work half done (one on character generators, one on using a slice algorithm and other line drawing enhancements) but I'm not sure when I'll get them up. 1 Quote Link to comment Share on other sites More sharing options...
orphean Posted March 25, 2021 Share Posted March 25, 2021 (edited) I know this topic is years old at this point but I've been having such a good time going through Sarkeizen's tutorial series. Sarkeizen if by some chance you read this: thank you so much for demystifying DHGR. I reached the (current?) end of the series and wanted more so I took a shot at doing a couple of the next steps mentioned. I expanded the drawing driver to be able to do filled rectangles and single plots. Then I took a crack at a character generator so I could at least print some text to the screen which worked out better than I thought it would! I then extended the driver to have a 'DrawString' command so its an easy matter of providing a couple bytes for location and an address to a null terminated string and it'll plot it out. Then I took a shot at rendering tiles and have got that up and running: Bonus shot of the kludgiest tile editor ever: I wrapped up the drawing commands into a set of macros which makes for some easy usage. The code for the textbox in the screenshot looks like this: dhrBeginDraw dhrSetWhite dhrDrawRect 20, 20, 60, 30 dhrDrawLine 65, 50, 71, 50 dhrDrawLine 66, 51, 70, 51 dhrDrawLine 67, 52, 69, 52 dhrPut 68,53 dhrSetDarkBlue dhrDrawLine 63, 52, 18, 52 dhrDrawLineCont 18, 18 dhrDrawLineCont 81, 18 dhrDrawLineCont 81, 52 dhrDrawLineCont 73, 52 dhrSetBlack dhrDrawString 22, 22, hello dhrEndDraw So at this point while I have a functional tile renderer I do not have a very performant one and am looking at ways to speed it up. The blitter is actually plotting each pixel one at a time with the associated lookups for main/aux ram, color, etc. I would love to find a way to somehow just copy bytes to the right place and speed it way up. Sarkeizen if you ever come back to this I would kill for a fast dhires block blitting routine! Edited March 25, 2021 by orphean 1 Quote Link to comment Share on other sites More sharing options...
Iamgroot Posted March 25, 2021 Share Posted March 25, 2021 (edited) Check out my Flying Toasters demo and see if it suits your needs. It has a very fast shape draw routine. FlyingToasters.dsk.zip Edited March 25, 2021 by Iamgroot 1 Quote Link to comment Share on other sites More sharing options...
orphean Posted March 25, 2021 Share Posted March 25, 2021 That looks great Iamgroot! Are you willing to put the listing for your DHR.DRAW anywhere? If not at least I have something to poke at with 6502Bench Quote Link to comment Share on other sites More sharing options...
Iamgroot Posted March 25, 2021 Share Posted March 25, 2021 (edited) There is a bug I have to correct first, which isn't easy to find. But the bug only happens when there is an odd number of pixels in the shape. The draw routine is pretty basic. It can draw a shape starting at any multiple of 4-bits or 1x color pixel. Just needs left coordinates of (0-139) and top (0-191) and will not draw off the screen. The shape table is set up exactly the same way as the hi-res shape table, except the data stores pixel colors and not direction bits. Starting with address of shape table: #0 = # of shapes #1 = is always zero #2.3 offset to 1st shape #4.5 offset to 2nd shape ... max # of shapes according to offset #0 (each shape has this setup) Width byte in pixels Height byte in lines - followed by data of W/2 x H bytes Note: the W/2 is used because each nybble holds the color of one pixel. Meaning 2 pixels per byte. Are you on Messenger at all, Orphean? Edited March 25, 2021 by Iamgroot Quote Link to comment Share on other sites More sharing options...
orphean Posted March 26, 2021 Share Posted March 26, 2021 (edited) Ah, I am not on Messenger Groot, at least not for some years. That said, I think I'm starting to understand this better. I decided to take a shot at a routine to clear the DHGR screen to any color since it would force me to really work through the structure of the screen memory. Since 4 bytes encodes 7 pixels on the screen, I made a routine that moved pre-computed byte values directly into screen memory in 4 byte increments (2 for Main, 2 for Aux): ; dhrClearScreenToColor ; Params: Color in A, 0-15 ; Destroys A, X, Y .proc dhrClearScreenToColor and #$0f tay lda clearColorLo, y sta CLRP lda clearColorHi, y sta CLRP+1 ldy #0 lda (CLRP), y sta A1 iny lda (CLRP), y sta M1 iny lda (CLRP), y sta A2 iny lda (CLRP), y sta M2 ldx #0 L: sta PAGE1 lda M1 sta $2000, x sta $2100, x sta $2200, x sta $2300, x sta $2400, x sta $2500, x sta $2600, x sta $2700, x sta $2800, x sta $2900, x sta $2A00, x sta $2B00, x sta $2C00, x sta $2D00, x sta $2E00, x sta $2F00, x sta $3000, x sta $3100, x sta $3200, x sta $3300, x sta $3400, x sta $3500, x sta $3600, x sta $3700, x sta $3800, x sta $3900, x sta $3A00, x sta $3B00, x sta $3C00, x sta $3D00, x sta $3E00, x sta $3F00, x inx lda M2 sta $2000, x sta $2100, x sta $2200, x sta $2300, x sta $2400, x sta $2500, x sta $2600, x sta $2700, x sta $2800, x sta $2900, x sta $2A00, x sta $2B00, x sta $2C00, x sta $2D00, x sta $2E00, x sta $2F00, x sta $3000, x sta $3100, x sta $3200, x sta $3300, x sta $3400, x sta $3500, x sta $3600, x sta $3700, x sta $3800, x sta $3900, x sta $3A00, x sta $3B00, x sta $3C00, x sta $3D00, x sta $3E00, x sta $3F00, x dex sta PAGE2 lda A1 sta $2000, x sta $2100, x sta $2200, x sta $2300, x sta $2400, x sta $2500, x sta $2600, x sta $2700, x sta $2800, x sta $2900, x sta $2A00, x sta $2B00, x sta $2C00, x sta $2D00, x sta $2E00, x sta $2F00, x sta $3000, x sta $3100, x sta $3200, x sta $3300, x sta $3400, x sta $3500, x sta $3600, x sta $3700, x sta $3800, x sta $3900, x sta $3A00, x sta $3B00, x sta $3C00, x sta $3D00, x sta $3E00, x sta $3F00, x inx lda A2 sta $2000, x sta $2100, x sta $2200, x sta $2300, x sta $2400, x sta $2500, x sta $2600, x sta $2700, x sta $2800, x sta $2900, x sta $2A00, x sta $2B00, x sta $2C00, x sta $2D00, x sta $2E00, x sta $2F00, x sta $3000, x sta $3100, x sta $3200, x sta $3300, x sta $3400, x sta $3500, x sta $3600, x sta $3700, x sta $3800, x sta $3900, x sta $3A00, x sta $3B00, x sta $3C00, x sta $3D00, x sta $3E00, x sta $3F00, x inx beq Done jmp L Done: rts .endproc AllBlack: .byte 0, 0, 0, 0 AllDarkBlue: .byte %00010001, %00100010, %01000100, %00001000 AllDarkGreen: .byte %00100010, %01000100, %00001000, %00010001 AllMedBlue: .byte %00110011, %01100110, %01001100, %00011001 AllBrown: .byte %01000100, %00001000, %00010001, %00100010 AllGrey2: .byte %01010101, %00101010, %01010101, %00101010 AllGreen: .byte %01100110, %01001100, %00011001, %00110011 AllAqua: .byte %01110111, %01101110, %01011101, %00111011 AllRed: .byte %00001000, %00010001, %00100010, %01000100 AllViolet: .byte %00011001, %00110011, %01100110, %01001100 AllGrey1: .byte %00101010, %01010101, %00101010, %01010101 AllLtBlue: .byte %00111011, %01110111, %01101110, %01011101 AllOrange: .byte %01001100, %00011001, %00110011, %01100110 AllPink: .byte %01011101, %00111011, %01110111, %01101110 AllYellow: .byte %01101110, %01011101, %00111011, %01110111 AllWhite: .byte $7f, $7f, $7f, $7f clearColorLo: .byte <AllBlack .byte <AllRed .byte <AllBrown .byte <AllOrange .byte <AllDarkGreen .byte <AllGrey1 .byte <AllGreen .byte <AllYellow .byte <AllDarkBlue .byte <AllViolet .byte <AllGrey2 .byte <AllPink .byte <AllMedBlue .byte <AllLtBlue .byte <AllAqua .byte <AllWhite clearColorHi: .byte >AllBlack .byte >AllRed .byte >AllBrown .byte >AllOrange .byte >AllDarkGreen .byte >AllGrey1 .byte >AllGreen .byte >AllYellow .byte >AllDarkBlue .byte >AllViolet .byte >AllGrey2 .byte >AllPink .byte >AllMedBlue .byte >AllLtBlue .byte >AllAqua .byte >AllWhite One thing that was unclear in Sarkeizen's writeup was which bit positions A, B, C, D, etc represented. After some munging around I figured it out, here are the documented bit values in case it helps someone else: ; A1 M1 A2 M2 ; PBBBAAAA PDDCCCCB PFEEEEDD PGGGGFFF ; 2341234 3412341 4123412 1234123 ; AAAA BBBB CCCC DDDD EEEE FFFF GGGG ; 1000 1000 1000 1000 1000 1000 1000 ; A1: %01100110 ; M1: %01001100 ; A2: %00011001 ; M2: %00110011 And I made quick spreadsheet to generate the 'packed' values of each of the four bytes for all 16 colors which is where the color values came from: And in the end I have a very fast routine that clears the screen to any color! So now for fast tile rendering, I just need to make the tiles a multiple of 7 for the width and, since I understand now how the bits relate to pixel data, I should be able to just copy the tile data directly into screen memory. This also lets me use page flipping if I see some tearing happening. I think my current block renderer is still useful for other purposes like when I need to read screen data to insert an image over existing image data. But I'm excited to see the performance of the new method. Edited March 26, 2021 by orphean Quote Link to comment Share on other sites More sharing options...
orphean Posted March 27, 2021 Share Posted March 27, 2021 So, by incorporating what I learned with my fast dhires screen clear routine into a tile render I managed to vastly speed up tile rendering. It's much, much quicker than my initial attempt but just slow enough to still cause a perceptible redraw. But, by using dhires page flipping, it is just about perfect. Plenty fast for scrolling and tile animation even when just dumbly drawing the entire map every frame. Here's a little example of the page flipping map renderer in action: I left space around the map for UI and such but I'm quite happy with the results so far. 1 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.