Well, would it still display the images on an unexpanded VIC? That's the main thing, IMO.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.
New screen / pixel editor for VIC-20
Moderator: Moderators
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.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.
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
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.Mike wrote:Even with that lastest version, I'd still have 942 bytes free when loading it into an unexpanded VIC?adric22 wrote:Unfortunately ... I think I just went over the memory limit on the unexpanded VIC.
I just assumed it was out of RAM.
- Mike
- Herr VC
- Posts: 4841
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
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).
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).
- Mike
- Herr VC
- Posts: 4841
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
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?
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.
Basically anytime one of these 4 routines were run:Mike wrote: Under which exact circumstances did the error occur?
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.
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..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.
- Mike
- Herr VC
- Posts: 4841
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
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.
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.
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.Mike wrote: I'm just curious about this, as you've got the program "working" for the wrong reasons,
-
- The Most Noble Order of Denial
- Posts: 343
- Joined: Fri May 01, 2009 4:44 pm
Hey,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
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
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
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
Last edited by matsondawson on Wed Oct 28, 2009 5:43 pm, edited 2 times in total.
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.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 )
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.