Changing the way SCREEN$ is loaded

2»

Comments

  • edited October 2008
    Tom-Cat wrote: »
    Was joking :-) ... since it is really hard to display 3 colours per 8x8 square ...

    Ok, now I am with you! :wink: Yes I know that the Spectrum can not really display 3 colours at once and AWM uses the trick with switching to the secondary screen at the right moment, but I still think it is quite amazing to see!

    It goes very fast unfortunaly, it would be ever nicer if the screen was displayed a little slower, but perhaps it is for technical reason that it must use that speed?
    Tom-Cat wrote: »
    the other video page could have something more interesting than just 15 colour pattern though, and you would actullay be able to see 4 colours per 8x8 square ;-)

    Do you know if any other game/loading scheme did use this technique? Should it be possible to actually use in-game to create "sprites" och backgrounds with 3-4 colours per 8x8 square?
  • edited October 2008
    Rickard wrote: »
    It goes very fast unfortunaly, it would be ever nicer if the screen was displayed a little slower, but perhaps it is for technical reason that it must use that speed?

    The only reason I can see is that the next block starts loading very quickly, so the screen "fade" must be done quickly too... no other technical reason there :)
    Rickard wrote: »
    Do you know if any other game/loading scheme did use this technique? Should it be possible to actually use in-game to create "sprites" och backgrounds with 3-4 colours per 8x8 square?

    Quite some games use this same loader and produce the same fading effect to show the loading screen... but in-game it would be REALLY hard to maintain the timing required to do this (since Speccy doesn't have video line interrupts like for example C64 has)...
  • edited October 2008
    Tom-Cat wrote: »
    Quite some games use this same loader and produce the same fading effect to show the loading screen...

    Do you have other examples of games with on this loader? I think I only saw it in AW-monty what I can recall, what be interesting to see others.
  • edited October 2008
    Rickard wrote: »
    Do you have other examples of games with on this loader? I think I only saw it in AW-monty what I can recall, what be interesting to see others.

    Avenger: http://www.worldofspectrum.org/infoseekid.cgi?id=0000351
    Future Knight: http://www.worldofspectrum.org/infoseekid.cgi?id=0000351
    Death Wish 3: http://www.worldofspectrum.org/infoseekid.cgi?id=0001299

    These are the ones I remember :)
  • edited October 2008
    Tom-Cat wrote: »
    These are the ones I remember :)

    Nice! Thank you!
  • edited October 2008
    So can we do it in BASIC or what?
  • edited October 2008
    chop983 wrote: »
    So can we do it in BASIC or what?

    If you mean loading different order it can be done in BASIC when you load line by line with 192 loaders.
  • edited October 2008
    Dr BEEP wrote: »
    If you mean loading different order it can be done in BASIC when you load line by line with 192 loaders.

    If you do that, you might want to figure out a way to prevent the 'Bytes:' messages from scrolling the screen away faster than it loads :-)

    (As a more sensible answer... no. The only tape load/save routines available from a stock Basic environment are the ones in the ROM, which don't support customising the order bytes are loaded/saved in - and trying to roll your own in Basic at the IN/OUT level would be several zillion times too slow. However, the custom loaders that other people have written in machine code don't necessarily require machine code knowledge to use.)
  • edited October 2008
    chop983 wrote: »
    So can we do it in BASIC or what?

    Some kind of "still-BASIC-mode" would be to have a BASIC program that includes some POKEs from DATA statements to make an almost similar copy of the ROM loader, but with different values for the border stripe colours.

    Not sure if that counts..
  • edited October 2008
    jp wrote: »
    Yup, the 2.50 mdr is slightly stuffed - the "run code" file looks to be fecked, but I think the rest of the files are good. Check out the "Alkatraz Utils.mdr" this seems to "RUN" with no problems - I'm not completely sure how to drive the whole package though. There is also a really unique assembler amongst this bunch of images, very microdrive friendly and looks to be a fairly slick 'custom' job.

    Ah, right, yeah the other one works. It's not very self explanatory though :( At least you can have fun with the screen load designer though :)
  • edited October 2008
    Just finished writing this program to draw the screen line by line. Doesn't load from tape yet, just wanted to understand how to draw line by line first. Its my version of a colour test card.

    Assemble in Spin, and run with,
    1 RANDOMIZE USR 4e4
    2 PAUSE 0
    3 GOTO 1
    Pressing a key undraws (?) the screen.
    		org 40000
    		out ($fe), a		; border black
    		ld hl, $5800		; attribute address
    		ld bc, $0000		; counter
    colour:		ld a, c			; get colour
    		and 71			; mask
    		ld (hl), a		; poke colour
    		inc hl			; next attribute
    		inc bc			; next colour
    		ld a, b			; check if
    		cp $03			; 768 bytes
    		jr nz, colour
    
    		ld a, (drawline+1)	; get screen poke byte
    		xor 255			; inverse
    		ld (drawline+1), a	; poke screen poke byte
    
    		ld a, $40		; top 1/3rd screen
    pokethird:	ld (screenaddress+2), a	; poke 1/3rd address
    screenaddress:	ld hl, $4000		; hl = screen address
    		ld b, 8			; b = line counter
    startline:	ld c, 32		; c = byte counter
    drawline:	ld a, 0			; a = screen poke byte
    		ld (hl), a		; poke to screen
    		inc hl			; next screen address
    		dec c			; decrease byte counter
    		ld a, c			; check number of bytes
    		jr nz, drawline		; continue if 32
    
    		dec b			; 1 line drawn
    		ld c, 224		; 224 bytes to next line
    nextline:	inc hl			; next screen address
    		dec c			; decrease counter
    		ld a, c			; check if 224 bytes counted
    		jr nz, nextline		; continue if hl = next line
    
    		push bc			; temporary delay loop
    		ld bc, $1000
    delay:		dec bc
    		cp b
    		jr nz, delay
    		pop bc			; end delay loop
    
    		ld a, b			; check if
    		cp 0			; 8 lines drawn
    		jr nz, startline	; if not draw next
    
    		ld a, (screenaddress+1)	; get lo-byte of screen address
    		add a, 32		; add 32
    		ld (screenaddress+1), a	; poke result back
    		cp 0			; check if 1/3 screen drawn
    		jr nz, screenaddress	; draw next character line if not
    
    		ld a, (screenaddress+2)	; get hi-byte of screen address
    		cp $50			; if bottom third complete
    		ret z			; end
    		cp $48			; if middle screen complete
    		jr z, bottomscr		; get bottom screen address
    
    		ld a, $48		; middle 1/3rd address
    		jr pokethird		; draw middle screen
    
    bottomscr:	ld a, $50		; bottom 1/3rd address
    		jr pokethird		; draw bottom screen
    
    
  • edited October 2008
    Woody wrote: »
    Does the same thing. Assembles with pasmo and likely to in SPIN without many changes.
    Assembles in Spin fine as is. Much better than mine, though mine was a first ever attempt at drawing to the screen. Now I know how it works I can learn quite a bit from your version. I've written another that prints a screen loaded to 32768 (binary .scr), with 1 line of attributes printed after 8 pixel lines (character line). But its displaying only in character lines at a time instead of pixel lines.

    Can't work out how to draw 1 pixel line in colour and keep the paper black.

    Thanks.
  • edited October 2008
    Woody wrote: »
    Does the same thing.
    Sometimes I really pity myself, I see the code and can't help myself but automatically start thinking how it could be improved further even if I really don't want to. :roll:
  • edited October 2008
    FrankT wrote: »
    Can't work out how to draw 1 pixel line in colour and keep the paper black.

    Do you mean draw 1 pixel line with for example red and white PAPER and INK and keep the undrawn pixel lines below still black?

    That is possible, see the Auf Wiedersehen Monty and Death Wish loaders discussed earlier, but I suspect it would be very difficult to code, as you have to switch between two screens in 128k mode at the exact right moments.
  • edited October 2008
    Where's Woody's code gone? I didn't save it and now I want to study it. :(

    I'll have a look at Auf Wiedersehen Monty's loader, but I wanted it drawn whilst loading, not after its loaded like the gremlin loader.
  • jpjp
    edited October 2008
    jp wrote: »
    ...There is also a really unique assembler amongst this bunch of images, very microdrive friendly and looks to be a fairly slick 'custom' job...

    Source code for the assembler here
  • edited October 2008
    FrankT wrote: »
    Where's Woody's code gone? I didn't save it and now I want to study it. :(

    I'll have a look at Auf Wiedersehen Monty's loader, but I wanted it drawn whilst loading, not after its loaded like the gremlin loader.

    The Auf Wiedersehen loader is subtle but VERY clever.
    It is 128K only (requires careful switching between the two screens).
    And brill music in the game of course.
Sign In or Register to comment.