New screen / pixel editor for VIC-20

Basic and Machine Language

Moderator: Moderators

saehn
Vic 20 Devotee
Posts: 235
Joined: Wed Apr 01, 2009 12:22 pm

Post by saehn »

adric22 wrote:Unfortunately.. I think I just went over the memory limit on the unexpanded VIC. I had to move the code lower and use the 3K expansion.. I still have another few routines to write, so i guess this program won't work on the unexpanded VIC after all.
Well, would it still display the images on an unexpanded VIC? That's the main thing, IMO.
adric22
Vic 20 Hobbyist
Posts: 143
Joined: Fri Mar 11, 2005 6:54 pm

Post by adric22 »

Mike wrote:I've found CPY $FB in the transfer loops. Since $FB is initialised at no place, you most probably meant CPY #$FB.

Unless $FB by chance contains a value >250 you'd be going to lose bytes at the end of the screen.
hey Mike, thanks for another bugfix.. I didn't do any of the optimizations you described, but I did change the $FB thing, you were right that was supposed to be #$FB.. essentially I'm done with the program now. It does what I designed it to do, and I guess I don't really need anything more from it at the moment.. However, feel free to optimize it or add features and just send me the source code and/or binaries.. This is an open-source program, after all. :-)

You can download my latest versions here:

Download source here: http://galaxy22.dyndns.org/vic20/screenedit.asm
Download binary here: http://galaxy22.dyndns.org/vic20/screenedit
User avatar
Mike
Herr VC
Posts: 4841
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

adric22 wrote:Unfortunately ... I think I just went over the memory limit on the unexpanded VIC.
Even with that lastest version, I'd still have 942 bytes free when loading it into an unexpanded VIC? :?
adric22
Vic 20 Hobbyist
Posts: 143
Joined: Fri Mar 11, 2005 6:54 pm

Post by adric22 »

Mike wrote:
adric22 wrote:Unfortunately ... I think I just went over the memory limit on the unexpanded VIC.
Even with that lastest version, I'd still have 942 bytes free when loading it into an unexpanded VIC? :?
I can't figure it out either.. I just kept adding more code and came to a point where messing with the SCRTEM area at the end of the file would cause the machine to reset. But there was nothing wrong with the code as making the program smaller by removing other stuff seemed to cure it. So eventually I just moved the code down and turned on 3K expansion and it seemed to solve the problem.

I just assumed it was out of RAM.
User avatar
Mike
Herr VC
Posts: 4841
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

From what I've seen, you statically allocate the memory, and that even within the object file scope (i.e. the initialised space for SCRTEM, and COLTEM). So, your program isn't supposed to write outside that space. When there's still memory free after the program is loaded, as indicated by PRINT FRE(0), your program isn't out of RAM.

How does the VIC "reset"? Does it return to the READY prompt, as if STOP/RESTORE had been pressed? This could indicate, that some parts of your program are overwritten during execution (in the $1000 version).
adric22
Vic 20 Hobbyist
Posts: 143
Joined: Fri Mar 11, 2005 6:54 pm

Post by adric22 »

How does the VIC "reset"? Does it return to the READY prompt, as if STOP/RESTORE had been pressed? This could indicate, that some parts of your program are overwritten during execution (in the $1000 version).
Yes.. it would just give a READY prompt as if runstop/restore had been pressed.
User avatar
Mike
Herr VC
Posts: 4841
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

So, with the current version (+3K expanded), I filled the memory - using VICE monitor - with stars (F 0403 1DFF 2A). Then I LOADed and RUNned your program, made some editing operations, including saving, and (re-)loading screens. Finally I checked the memory above your program for stray writes.

I couldn't find anything suspicious, however.

Under which exact circumstances did the error occur?
Last edited by Mike on Wed Oct 28, 2009 11:30 am, edited 1 time in total.
adric22
Vic 20 Hobbyist
Posts: 143
Joined: Fri Mar 11, 2005 6:54 pm

Post by adric22 »

Mike wrote: Under which exact circumstances did the error occur?
Basically anytime one of these 4 routines were run:

LOADFILE
SAVEFILE
LOADSCN
COPYSCN

Anything that reads or writes to the temporary screen area seemed to cause the reset. I went into the code and commented out any JSR calls to those 4 routines and the program ran stable after that.
User avatar
Mike
Herr VC
Posts: 4841
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

Could you provide the problematic binary as download then? I'm using another assembler, and don't have your assembler installed on my system.
adric22
Vic 20 Hobbyist
Posts: 143
Joined: Fri Mar 11, 2005 6:54 pm

Post by adric22 »

Mike wrote:Could you provide the problematic binary as download then? I'm using another assembler, and don't have your assembler installed on my system.
I don't really have a binary anymore.. nor do I have the source where the problem existed. I'd have to go modify my existing source to put it back to unexpanded VIC settings and recompile it..
User avatar
Mike
Herr VC
Posts: 4841
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

Should be as easy as altering the ORG address, commenting out the $0400 stub, and bringing in the $1000 stub again.

If there are any more alterations necessary within the source, you'd not using the assembler in a sensible way.

I'm just curious about this, as you've got the program "working" for the wrong reasons, by relocating it. As there had been enough available RAM in both cases, there must have been a subtle reliance upon fixed addresses somewhere in it - which also eluded me by reading over your source code.

To find the real cause of the bug now would require to reproduce it.

However, if it can't be reproduced anymore, even when you re-assemble the program for unexpanded VIC, well, then we can't do much about it anymore.
adric22
Vic 20 Hobbyist
Posts: 143
Joined: Fri Mar 11, 2005 6:54 pm

Post by adric22 »

Mike wrote: I'm just curious about this, as you've got the program "working" for the wrong reasons,
Yeah, but the sad truth is that I took 2 days off from coding on my Vic-20 game called "defending Planet X1" in order to write this utility so that I could create a nice intro screen for the game. The editor does what I need it to do, and I doubt anyone else will be using it much based on the few responses I got.. So it is time for me to move on and get back to the game coding. If I write any games in the future, I'll probably be using this program again. And I might even need to modify a few variables here and there and it should work on the C64 too.
matsondawson
The Most Noble Order of Denial
Posts: 343
Joined: Fri May 01, 2009 4:44 pm

Post by matsondawson »

adric22 wrote: You can download my latest versions here:

Download source here: http://galaxy22.dyndns.org/vic20/screenedit.asm
Download binary here: http://galaxy22.dyndns.org/vic20/screenedit
Hey,

Just having a look ay your source, very readable.
Got a few suggestions for smaller code (I know, I know, you aren't working on it anymore :) )

Code: Select all

Instead of:
LDA	#$01
STA	CURCOL
LDA	#$00
STA	MODE	; Set mode to character edit.

you can do:
LDX #$01
STX CURCOL
DEX
STX MODE  ; woo hoo 1 byte saved :P

Code: Select all

On your loops e.g:
	INX
	CPX	#$00  ; <--- Not needed
	BNE	COLCL1

You don't need to do the CPX #0, that is already done by INX

Code: Select all

In LSR's:
	CLC          ; <---- CLC is not needed
	LSR		; Divide by two

LSR doesn't use the carry flag for input, and will set it anyway afterwards.

Code: Select all

This type of code:
	AND	#%00000001 	; Is the pixel on left or right of the character?
	CMP	#%00000001
	BNE	PLOTH1

Try this instead:
	PHA 	; Is the pixel on left or right of the character?
	PLP
	BCC	PLOTH1

Code: Select all

	; Easy one here:
	LDA	#$01
	LDX	#$08		; Device 8
	LDY	#$01

	; 1 byte saved like this     
	LDA	#$01
	LDX	#$08		; Device 8
	TAY
Unneeded CMPs:

Code: Select all

MOVEUP	LDA	MAPY
	CMP	#$00 ; <--- These are not needed, done by LDA
	BNE	MOVU1
	RTS

Code: Select all

Unneeded CLC's on ASLs.
	CLC   ; <--- Not needed
	ASL
And last of all the keyboard routine could save more than 100 bytes if it were more like this:

Code: Select all

KEYTABLE
  !BYTE $1D, <MOVERT, >MOVERT
  !BYTE $9D, <MOVELF, >MOVELF
...
  !BYTE $00  ; last entry must be this

KEYWAIT
  JSR	$FFE4	; Check if key has been pressed.
  LDX #0

LOOP:
  CMP KEYTABLE,X
  BEQ FOUND_KEY
  INX ; Check next key
  INX
  INX
  LDY KEYTABLE,X
  BNE LOOP
  JMP KEYWAIT
  
FOUND_KEY
  ; branch to instruction
  INX
  LDA KEYTABLE,X
  STA dynamic_jsr+1
  INX
  LDA KEYTABLE,X
  STA dynamic_jsr+2
dynamic_jsr:
  JSR $0000 ; dynamic inst
  JMP KEYWAIT 
Cheers Matt
Last edited by matsondawson on Wed Oct 28, 2009 5:43 pm, edited 2 times in total.
TBCVIC
Vic 20 Hobbyist
Posts: 127
Joined: Thu Mar 05, 2009 3:38 am

Post by TBCVIC »

Ah, never used PLP myself, had to look that up. That was a cool trick.
Ola Andersson
Image
adric22
Vic 20 Hobbyist
Posts: 143
Joined: Fri Mar 11, 2005 6:54 pm

Post by adric22 »

matsondawson wrote:Just having a look ay your source, very readable.
Got a few suggestions for smaller code (I know, I know, you aren't working on it anymore :) )
Thank you for the suggestions.. Some of that I didn't know. Other bits of it I did know, but I tend to do weird things to make code more readable. For example, many of the CMP instructions I use, even if comparing to #$00 is to help me look at the code and see what is going on. Also, using stuff like #%00000001 in a compare statement helps me easily see that I'm checking for bit 1. I realize there is that 6502 command called BIT I could also use in many circumstances.. but I'm not coding a demo, and so saving an instruction cycle or two isn't that important to me. Good working code that is easy to read and debug is, though.

However.. I'm running up against some speed issues as I continue to press along with my game. It is taking a little too long to draw the screen, causing flickers here and there. I may require some optimizations on that.
Post Reply