| |
Conrad
Registered: Nov 2006 Posts: 849 |
Question/Problem about Dreamload
I'm having a bit of trouble with Dreamloader for the last few weeks now, not saying that I'm a lamer at using it :) it's more to do with the disks (testing on WinVice with 1541-I drive btw).
What it is, most of the files on the disk load great as normal, but for some files it causes the loader and program IRQ to freeze.
I have a feeling it's something to do with where the allocated blocks of the file are stored in the BAM, because this problem happens after I transfer a certain file to the D64 image, or make a duplicate of the disk. I'm currently using D64 Editor V0.028 to put files onto a d64, so I'm not too sure if it's that program that's causing it, or Dreamloader.
Just to let you know that the code for the demo/whatever is set up properly and that all load addresses of each file to load are correct and will not overwrite any code areas in memory. I've had this same problem with another production as well.
Can anyone tell me what I might be doing wrong?
cheers.
EDIT: Here's the source code I'm using to load a file, if you may need to see:
;Prepare loader and start of demo...
*=$8f00
jsr $8000 ;Initialise disk-drive fastloader.
bcc load_setup_ok ;If no carry, init successfull.
inc $d020 ;Else, flash border, saying no drive is connected, etc.
jmp $8f00 ;Loop back to check again.
load_setup_ok
jmp irqstart ;Call main IRQ to setup and start demo.
;This part is JMPed to after IRQ is set up.
load_restart
jsr $0506 ;Shut up the disk-drive.
load_next
lda #$00 ;Shift next two files to the file handle to load.
sta load_start+1 ;
load_third
lda #$00 ;
sta load_next+1 ;
lda #$00 ;
sta load_third+1 ;
load_start
lda #$00 ;Main driver loop to check for next file to load.
beq load_next
clc
adc #$2b ;Offset to store char as "@" onwards
cmp #$3f ;Check if the char is a "?" (invalid filechar)
bne *+4
lda #119 ;Set it as another unique symbol
sta load_filename
jsr $0509 ;Wake up the disk-drive.
load_retry
ldy #>load_filename ;and load the file...
ldx #<load_filename ;
lda #$02 ;(first 2 chars required from filename)
jsr $0500 ;
bcs load_error ;If no carry, load was successful.
lda load_start+1 ;Do we need to restart the tune after load?
cmp #$11
bcc load_restart ;Skip if not a tune loaded.
lda #$00 ;Else start loaded music.
tax
tay
jsr $1000
jmp load_restart
load_error ;If load unsuccessful, check the right disk is inserted.
...blah...blah...blah
load_filename
!text " *"
|
|
| |
hollowman
Registered: Dec 2001 Posts: 474 |
I dont have any answer but I just want to say that I've had some similar experiences when using dreamload, dfi images and mmc64, that suddenly it wouldnt load some file, although I was sure that I hadnt made any changes that could affect it.
|
| |
Conrad
Registered: Nov 2006 Posts: 849 |
hmm. Maybe I should do more trial and error on the demo code, as it is quite a large project for a one-filer. The bigger it is, the more chance of crashing. |
| |
Conrad
Registered: Nov 2006 Posts: 849 |
Okay, I'm still getting this awkward bug, and I have got closer to what the problem is...
What it is, I have this particular file stored on a .d64, it's 15 blocks and is completely error free, alongside more error-free files.
The start TRACK/SECTOR of the file is 32 , 0 and these numbers are correctly stored in the directory sector.
What happens though (as I have been watching the track/sector numbers on Vice in true drive emulation) when dreamloader reads the directory, it sets the read head straight to track/sector: 17, 0 - which is obviously incorrect for this particular file, thus causing the program to crash as it is just loading 0's.
I have tried everything -- dragged out and dropped the file back in which automatically allocates sectors correctly, but the same problem happens (goes to a different start track/sector.)
I have a feeling this is either Dreamloader has a bug, or, I as missing something out in the demo code. In the code I have used PHA and PLA correctly, as the loader does load all the other files great.
.... HELP?! ... |
| |
Ninja
Registered: Jan 2002 Posts: 411 |
I think you are using an old version of dreamload, which had a bug accessing tracks 32 and above. Get the newest version here (and forgive us our bad announcement policy = there is hardly none :( )
http://developer.berlios.de/projects/rrtools/
(updated the CSDb-entry now, sorry for the confusion) |
| |
Conrad
Registered: Nov 2006 Posts: 849 |
Thank you Ninja. I'm positive this will improve the problem (I hope anyway).
and BTW, props to you and DocBacardi for this outstanding loader, it's very useful indeed :) |
| |
Conrad
Registered: Nov 2006 Posts: 849 |
Tell you what guys, just forget this topic completely. I just realized the problem I had was: Two filenames in the directory both began with the same letter i.e. "DEMO" and "D." thus loading the main code which de-facto caused a crash.
Once again .... i screwed up :DD
Thanks for your inputs anyway. |
| |
gregg Account closed
Registered: Apr 2005 Posts: 56 |
Hi, I'm having a problem with DreamLoad too. I'm trying to use the LoadTS interface to read a disk (1541) sector by sector, track by track. However, DreamLoad errors out after successfully having read the 1st sector, most of the time it hangs when trying to read the 2nd sector or when trying to reset the drive. Any idea what I'm doing wrong here?
!to "loadtest.prg",cbm
!cpu 6510
!source "mylib.a"
DL_init = $2000
DL_base = $4000
; basic loader
*= $0801
!byte $0b,08,0,0,$9e
!text "4096"
!byte 0,0,0
*=$1000
init sei
jsr DL_init
bcc +
lda #<init_error_msg
ldy #>init_error_msg
jmp $ab1e
+
; load 1st zone tracks
loadz1 ldx #1
-- ldy #0
- jsr DL_base+3
bcc +
lda #<load_error_msg
ldy #>load_error_msg
jsr $ab1e
jmp DL_base+15
+ ; do stuff with loaded sectors here :)
inc $d020
iny
cpy #21
bne -
inx
cpx #18
bne --
jmp DL_base+15
;--------------------------------------------------------------------------
; text messages
init_error_msg
!pet "error initializing loader!"
!raw $8d, 0
load_error_msg
!pet "error loading a sector!"
!raw $8d, 0
;--------------------------------------------------------------------------
; dreamload
*=$2000
!binary "dload.prg",,2 |
| |
Style
Registered: Jun 2004 Posts: 498 |
Ive never used it, but are you sure that dreamload retains the contents of the registers during the JMP DL_BASE+15?
|
| |
gregg Account closed
Registered: Apr 2005 Posts: 56 |
I don't think it matters, DL_base+15 only resets the drive and after that returns to BASIC. I just tested it on the real machine, it never hangs on my 128D but it does so in VICE with 1541-II emu. :)
[edit]
OK, of yourse you meant DL_base+3... and you were right, sorry for being so stupid. Works like a charm now.
OK, but it turns out DreamLoad is quite slow for such purposes, even after tweaking interleave somewhat (I suppose interleave of 10 is OK?). I need a a fast track reader I guess. Hints? |
| |
Ninja
Registered: Jan 2002 Posts: 411 |
Well, optimal interleave is a complicated problem; still I think 8 is a way better everyday value than 10. If this does not help and your project is 1541 only, then you might want to ask Krill for his loader which is more independant on interleave. Of course, if you want max speed and do not have interruptions, then you should go for completely different types of loaders. |
| |
gregg Account closed
Registered: Apr 2005 Posts: 56 |
My project is 1541-only and I don't have interruptions. At least only planned ones between reading the tracks. I already asked Krill about his loader. I'll give it a try as soon as I have it.
A non-IRQ-loader would probably be faster/better suited for this, as you pointed out though. But where can I find such loaders? Everyone only wants IRQ loaders! :)
Maybe it's possible to rip such a loader right from a fast disk copier. |
| |
tlr
Registered: Sep 2003 Posts: 1790 |
Quote: I think you are using an old version of dreamload, which had a bug accessing tracks 32 and above. Get the newest version here (and forgive us our bad announcement policy = there is hardly none :( )
http://developer.berlios.de/projects/rrtools/
(updated the CSDb-entry now, sorry for the confusion)
Svn-repository + using jam, yay!
I've wanted to have a go at using jam for a long time. I'm using make/automake currently. |
| |
Style
Registered: Jun 2004 Posts: 498 |
gregg: yeh sorry, DL_BASE + 3 :) glad it worked out :) |