It is currently Fri Apr 18, 2014 3:37 pm

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 7 posts ] 
Author Message
PostPosted: Sat Sep 29, 2007 5:19 pm 
Offline

Joined: Sat Sep 29, 2007 4:15 pm
Posts: 5
Hi,

First i'd like to greet everybody. I was first introduced to the Commodore 64 back in -85. Thats when i got my own C64. Although, there were already lots of software available, i interrested more and more about developing software myself. And i did some assembly coding, small demos and stuff. After two years i moved to Amiga but C64 is still the machine i like. Years passed and every now and then i studied the design of C64 and 6502. I become interrested about processors and compilers. Few years ago i started to develope my own multiplatform compiler toolchain. Progress is slow but maybe one day the whole thing is ready. Propably ever, but that doesn't matter. However, thing which lead to my problem is that, because i've finished my assembler, i thought it would be cool to code a little demo and test the assembler a bit. So, i coded a little iff-viewer for C64 and 1541.

Now into my problem. I tested the demo with Vice and everything seems to work. My assembler outputs a .prg file and it could be run in vice without problems. The demo loads an .iff-files from the device 8 and Vice kindly mapped the whole Windows directory as a big disk. So i though, well, the demo is ready. I want to run it in the REAL C64. Hell, it uses interlaced display and all. So i generated an .d64 image which contained my demo.prg and bunch of .iff files. That image didn't run in vice at first time but i sorted it out, maybe. I manage to generate a .d64 image which worked with Vice but when i used my MMC64 to transfer it to a real 1541 floppy the demo didn't work any more.

I have the C64 reference manual and the documentation there is very poor. Thats why i suspect that i coded the file handling such an incompatible way that it works in the Vice with certain circumstances but not in the real C64.

I include my file handling module here so somebody with good knowledge can check it out. Or point me to a place where i could find a proper documentation/examples.

Regards

Code:

SETNAM   = $ffbd
SETLFS   = $ffba
OPEN   = $ffc0
CHKIN   = $ffc6
CLOSE   = $ffc3
GETIN   = $ffe4

FILE   = 5
DEVICE   = 8
SEC      = 0

.code
 ;**************************************************************
 ; openfile: - Open a file for reading
 ; INPUTS:
 ;  - X, LO-byte of filename
 ;  - Y, HI-byte of filename
 ; RETURNS:
 ;  C=0 if succesfull
 ; REMARKS:
 ;  Filenamebuffer pointed by X/Y registers is
 ;  in ASCII and zero terminated.
 ;
.public openfile
openfile:
   stx fn+1      ; calculate length of filename
   sty fn+2
   ldy #$ff
ofloop:
   iny
fn:   lda $ffff,y
   sta filename_buf,y
   bne ofloop
   tya
   ldx #lo(filename_buf)
   ldy #hi(filename_buf)
   jsr SETNAM
   lda #FILE
   ldx #DEVICE
   ldy #SEC
   jsr SETLFS
   jsr OPEN
   bcs exit
   ldx #FILE
   jsr CHKIN
   clc
exit:
   rts

.bss
filename_buf:   ; temporary storage for a file's name
   ds.b 16+1

.code
 ;**************************************************************
 ; closefile: - Closes a file
 ;
.public closefile
closefile:
   lda #FILE
   jmp CLOSE

.code
 ;**************************************************************
 ; readfile: - Reads a file
 ; INPUTS:
 ;   - A, Amount of bytes to read
 ; REMARKS:
 ;   Read bytes are stored to a global 'buffer'
 ;
.public readfile
readfile:
   sta rfcomp+1
   stx rfoldx+1
   sty rfoldy+1
   lda #0
   sta rfptr+1
rfloop:
   lda #FILE
   jsr GETIN
rfptr:   ldx #$ff
   sta buffer,x
   inx
   stx rfptr+1
rfcomp:   cpx #$ff
   bne rfloop
rfoldx: ldx #$ff
rfoldy: ldy #$ff
   rts

.bss
.public buffer
buffer:   ; file read buffer
   ds.b 256



Top
 Profile  
 
 Post subject:
PostPosted: Sun Sep 30, 2007 1:03 am 
Offline

Joined: Sat Sep 29, 2007 4:15 pm
Posts: 5
Ok, i did some debugging with the real C64 and AR6 cartridge and found out that the file handling works perfectly. But only when i don't mess with IRQ frequency and register in $DD00. I checked the memory map and it turns out that IEC signals are driven by that register too, ops. I need it to switch CIA bank for an interlaced display.

So, my strategy is as follows:
1. implement multisourced IRQ handler(CIA and raster interrupts)
2. Don't touch to other bits in $DD00

Looks promising...


Top
 Profile  
 
 Post subject:
PostPosted: Sun Sep 30, 2007 5:08 pm 
Offline

Joined: Sat Oct 14, 2006 9:30 am
Posts: 140
To switch graphics bank while loading, set dd00 to 0, then write the bank into $dd02 instead (the DDR). If you set the DDR bit to a 0, the input will float high. If you set the DDR bit to 1, it'll pull low.

Also, use an IRQ loader instead of the kernal loader. DreamLoad and Krill's loader are popular choices, and you can roll your own based on the Covert Bitops rants.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Sep 30, 2007 7:25 pm 
Offline

Joined: Sat Sep 29, 2007 4:15 pm
Posts: 5
MagerValp wrote:
To switch graphics bank while loading, set dd00 to 0, then write the bank into $dd02 instead (the DDR). If you set the DDR bit to a 0, the input will float high. If you set the DDR bit to 1, it'll pull low.


Can you give more info why bank should be switched in that way? Either way, the other bits must be preserved.

MagerValp wrote:
Also, use an IRQ loader instead of the kernal loader. DreamLoad and Krill's loader are popular choices, and you can roll your own based on the Covert Bitops rants.


This isn't going to be a such a small demo as i first imagined... But you're right, i noticed that kernel load messes with i-flag and/or occasionally takes too much time in IRQ. As a solution i was thinking of using CIA driven NMI-interrupt, started during vertical blanking period. But the IRQ-loader would be more elegant solution.

Thanks


Top
 Profile  
 
 Post subject:
PostPosted: Sun Sep 30, 2007 7:48 pm 
Offline

Joined: Thu Jan 12, 2006 10:10 am
Posts: 177
leegoukko wrote:
MagerValp wrote:
To switch graphics bank while loading, set dd00 to 0, then write the bank into $dd02 instead (the DDR). If you set the DDR bit to a 0, the input will float high. If you set the DDR bit to 1, it'll pull low.


Can you give more info why bank should be switched in that way? Either way, the other bits must be preserved.

With some thought you can let kernal handle IEC bits at $dd00 and swap VIC-II bank with $dd02, without one affecting the other so no AND/OR needed, and it's safe to change one in IRQ/NMI and other in the main code.



Quote:
As a solution i was thinking of using CIA driven NMI-interrupt, started during vertical blanking period.

This will only work with kernal routines if you keep your NMI under 40 cycles total and make sure it won't happen on bad line. That 40 cycle count includes 7 cycles for firing the NMI and another 7 cycles for RTI, leaving you 26 cycles which is enough for switching VIC-II bank but not much else.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Sep 30, 2007 9:12 pm 
Offline

Joined: Sat Sep 29, 2007 4:15 pm
Posts: 5
tnt/beyond force wrote:
Quote:
As a solution i was thinking of using CIA driven NMI-interrupt, started during vertical blanking period.

This will only work with kernal routines if you keep your NMI under 40 cycles total and make sure it won't happen on bad line. That 40 cycle count includes 7 cycles for firing the NMI and another 7 cycles for RTI, leaving you 26 cycles which is enough for switching VIC-II bank but not much else.


Thanks for the info, I will try that consept. The NMI is going to be handled in the vertical blanking period, so there's no bad lines and only thing what it does is switch VIC bank and toggle one horizontal scroll bit. I think that fits to those specifications. BUT, i will need an NTSC/PAL detection to know what timer value i need to use. So, i'm seriously thinking the IRQ-loader thing.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 01, 2007 2:00 pm 
Offline

Joined: Sat Oct 14, 2006 9:30 am
Posts: 140
leegoukko wrote:
So, i'm seriously thinking the IRQ-loader thing.


They exist to solve this exact problem :)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group