Loading multiple data files into memory - HELP!!!

[JonBrawn]

Wotcha!

I'm using a VIC-20 with extra memory in the 3K area, plus blocks 1, 2, 3 and 5.

I have a BASIC program at $1200, which is trying to load some machine code at $0400 and some data files at address $2000 onwards. The machine code file and each data file starts with the two bytes describing its target address. The very last data file is terminated with a zero byte. There are twenty data files, each 1250 + 2 bytes long.

The relevant bits of my BASIC are:

Reset top of BASIC memory (I think):

Code: Select all

10 poke51,0:poke52,32:poke55,0,poke56,32:clr

EDIT: Apparently I have become a victim of "cargo cult programming" and I don't need the POKEs to 51 and 52. I shall purge them in the re-write.

Speed up the floppy drive:

Code: Select all

26 open 1,8,15,"UI-":close 1

Load machine code file. The two-byte header is $0400

Code: Select all

30 sys 57809("dac.prg"),8,1:poke780,0:sys65493

Load each section of code. There are 20 of them; in DATA statements, they load back-to-back-to-back in memory, and each file begins with a 2-byte header containing the intended load address. The last file is terminated by a zero byte; none of the other files contains zero bytes.

Code: Select all

410 read l$
420 if l$="end" then 500
430 sys 57809(l$),8,1:poke780,0:sys65493
440 next

However, after it's chugged through the best part of 24KB of data, there is a zero byte after the end of the first data block, at offset 1252.

What am I doing wrong?

Jon.

[Mike]

The code looks fine. I'd suspect one of the data files is the culprit.

With a monitor, you can check the data files load correctly and stay within their boundaries by first filling memory with F 2000 7FFF 2A (any non-$00, non-$FF fill byte is good enough here), loading the data files one at a time with L "...",8 (the extra ",1" not required here) inspecting memory with M xxxx yyyy (including a few bytes before and after the intended range to ensure the data file did not spill into a neighbouring range) and repeating those three steps (Fill, Load, Memory Dump) for all files.

Is there any specific reason you fill the $2000..$7FFF address range from multiple files?

[JonBrawn]

Is there any specific reason you fill the $2000..$7FFF address range from multiple files?

It's to demo one of the features of Victor, the 6560 replacement. Victor can support direct access to the audio DAC from user programs, so I wanted to demonstrate this by playing a few seconds of the intro to some tunes from the '80s. Each tune is 3 seconds long but requires 24KB of data (so, the sample rate is a pretty grotty 8KHz). If you load the data as one long 24KB file into memory, it takes around 2 minutes, and my audience will have grown tired and wandered off by the time it's finished, so I wanted to use a progress bar. Splitting the one monster 24KB file into 20 smaller files allows me to load a file, increment the progress bar, load the next file, increment the progress bar and so on, so the progress bar gets updated every few seconds. People are a bit less inclined to get bored and wander off as they see progress is being made. There are six tunes, each using 20 data files.

Jon..

[groepaz]

If you are using kernal, you can use one file and patch into the STOP vector (iirc) to update the progress bar (or do whatever during load)

[JonBrawn]

This is embarrassing. I did have it working, and then I realized that if I Camel Cased the file names, then when it's reporting which file its processing, it would look nicer. However, I forgot to update the data files on the SD Card to match the filenames in the program, so yay for me! File not found errors.

Error handling has been added, the files are correctly named, and it works again. Thanks for your help!

[JonBrawn]

While I appreciate that part of the retro experience is waiting for files to load from tape or disk, there are occasions where it'd be nice not to have to wait two minutes for something to load from disk, especially if you've got a dozen somethings that you're going to work through. With that in mind, are any disk accelerators currently available for the VIC-20 and 1541? And, if so, where can I find them, as my internet search foo has failed me completely on this one!

[srowe]

Most accelerators are based on the JiffyDOS protocol. SD2IEC supports it, I wrote an implementation for the VIC-20

https://www.sleepingelephant.com/ipw-we ... hp?t=10436

[Mike]

[...] are any disk accelerators currently available for the VIC-20 and 1541? [...]

As follow-up about an alternative to zippy or SJLOAD for NTSC VIC-20 in another thread, you can download a disk image with TurboDisk here

https://dateipfa.de/.Public/denial/1985-07.d64 (mirrored from commodoreserver.com)

The file "TDISK/VIC" installs TurboDisk at the end of BASIC RAM and protects it there. For your application, there's still a clash with the sample data you load there. You can 'fool' TD into using BLK5 instead by temporarily altering the end of BASIC RAM as follows:

Code: Select all

POKE55,0:POKE56,192:CLR

LOAD"TDISK/VIC",8

RUN

POKE55,0:POKE56,128:CLR

... or POKE55,0:POKE56,32:CLR if you're going to protect the entire range of BLK1..3 anyway.

While I'd presume TD correctly handles BASIC programs with just the ",8" relative load, I am not quite sure about absolute loads for machine code or data with ",8,1" - you'd need to test that by yourself. Also I don't know whether TD supports other device numbers than 8.

[JonBrawn]

While I'd presume TD correctly handles BASIC programs with just the ",8" relative load, I am not quite sure about absolute loads for machine code or data with ",8,1" - you'd need to test that by yourself.

It seems to function for the KERNAL calls I'm making from BASIC, which are essentially a sequence of 8,1 loads into consecutive memory areas. It's not the most excellent speedup, but it's better than a slap on the belly with a wet fish, so I'll take it.