I am working up a VIC 20 with a 65C816. My prototype works, I think, and it has 128K of memory. My question involves saving data/programs that extend into bank 1 and above with Commodore drives...is it possible? Did the SCPU need a CMD drive to do it?

I don't recall direct loading into expanded memory on the SuperCPU as a built-in feature. The file format only includes a 2-byte load address, and the KERNAL routines still are only aware of a 16-bit address space. CMD did not rewrite the KERNAL to be a 24-bit system.

Certainly the drives themselves are unaware of what the host machine is doing with the data, so which drive you use is irrelevant. You just need your own user-space loading routines to shove the loaded bytes into the higher memory areas. You can pretty easily use the KERNAL to open & read bytes from any compatible device, and then store them where you want, bypassing the specific call to the legacy LOAD routine.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Of course it's possible, but be sure to read White Flame's response again before going further.

The on-disk format of a CBM program file consists of a little-endian load address, followed by the program text. It must be understood that the disk itself knows nothing about this, only that a bunch of bytes have been stored in a file that the CBM DOS considers to be a program (type PRG). When the kernel LOAD function is called the kernel sets up the disk to be a TALKer (refer to the operation of IEEE-488 if you aren't sure what that means) and the computer to be a LISTENer. The kernel then repeatedly executes a low-level function called ACPTR ($FFA5), which grabs a byte from the TALKer and puts it into RAM.

In a non-relocating load, the load address in bytes 0 and 1 of the file is used as the start address. Otherwise, the load is to an address specified as part of the LOAD kernel call. In both cases, after a byte has been written to RAM a pointer is incremented to point at the next location in which to write. This process continues until the disk signals that the end-of-data (EOD) has been reached. EOD is determined by examining the ST kernel flag in zero page after each call to ACPTR. I seem to recall that in the VIC-20, C-64 and C-128 kernels it was possible to hang the serial bus by calling ACPTR after EOD had been signaled.

Since the kernel only recognizes 16-bit load addresses, you would have to write a new version of the kernel's SAVE function to generate more load information in the program file. If I were doing it, I'd arrange the following:

Code:

 File
Offset   Function
——————————————————————————
  00     Load address LSB
  01     Load address MSB
  02     Load bank
  03     Unused, set to $00
  04     Start of data
——————————————————————————

In the unmodified kernel, when a SAVE is executed, the kernel commands the disk to be a LISTENer and the computer becomes the TALKer. The save itself iteratively calls the low level CIOUT function ($FFA8) to write to the disk. The first and second bytes are the starting address of the block of RAM to be saved, after which bytes grabbed from RAM are written. In your new SAVE function, you'd write the load address, then the bank, both of which would be expressed as 16-bit values. Once the load information has been written you can write your data.

Similarly, a new LOAD function would have to be written to understand your file format. Again, you'd read bytes $00-$03 to get the load address, and then iteratively call the ACPTR function to load the actual text/data. As part of loading and saving, you will need to allocate a 24-bit pointer on zero (direct) page for long indirect access, that is, [<dp>],Y addressing. As the kenel ROM is effectively in bank $00, using long indirect saves you the trouble of fiddling with banks as you load or save. You would set the 65C816's DB register to $00.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks guys. I figured that's the way to do it. I like to see what others have done to tackle the issue.

My supervixen expansion (https://mewe.com/join/Vic-20) has a 65c02 and an integrated SD card reader. So all routines are custom, but available at boot. File format is the same (file system is FAT32). There is also 1064KiB of memory with banking, so you put the loaded data were you want it.

Any pictures of your 65816 Vic-20?

Unfortunately, that site requires me to register just to see the content.

_________________
--
Torfinn

Yes, very disappointing. Has it been set up this way by accident, perhaps? It seems rather unfriendly -- not the sort of choice that would be made deliberately. Perhaps it's a default of some kind.

kakemoms, it might be helpful if you'd mention the problem to the folks in charge -- if you have a spare moment, that is -- no pressure. Thanks!

( Administrators of other groups requiring registration to view take note. )

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

(I think this is a "feature" of mewe, which hoped to pick up the bulk of the leftovers when g+ closed. But it's constructed as a walled garden so everyone in there is captive. I felt it wasn't the solution for me. Ultimately that's why I set up https://retrocomputingforum.com)

Ok. Well, mewe is more concerned about privacy that facebook, so it may be the cause. You don't need to give any private information to register.

Anyway, most of the work I've done over the last two years can be seen on denial: http://sleepingelephant.com/ipw-web/bulletin/bb/viewtopic.php?f=11&t=8511

Thanks for the new link! I much prefer the open web.

I have been looking for something like this myself, and I think that this format makes sense. They only thing it lacks is the ability to see the difference between a 16-bit load address and a 24-bit or 32-bit one. That could be implemented by using a different extension (to the normal .prg). Possibilities are endless, but .p24 or .prog would work.