Jump to content

Proto #2 support in GitHub ROM, Emulator & Documentation


Recommended Posts

Posted (edited)
On 5/26/2021 at 11:58 AM, ZeroByte said:

I think it loads to current bank and if it reaches C000, it wraps to A000 and INCs the ram bank.

in other words, you set the desired first bank prior to calling load.

Ah, I found it, it's not the Bank, it's the VRAM, where SA=2-17 are the high four bits of a VRAM.

So bits %0001111 of the SA are already allocated by LOAD, so a bit to say "this is headerless" would have to be (header SA)+32 (or +64 or +128), and if bit5 is set, the load is headerless: a SA=32 load goes where set in XY, a headerless SA=34-49 load takes the lower sixteen bits from X/Y, and a secondary address of 33 should go to $A000.

So the changes needed to Kernel LOAD is to start with a bit test of the SA, if SA=33, store $A000 where the first two bytes of the file are stored, if SA>33, store X/Y there, then if bit5 is set, clear it and set a new HeaderlessLoad status bit or byte.

Then in the routine where the first two bytes are read, skip the reading of the first two bytes if the "HeaderlessLoad" bit/byte is set, and clear that bit/byte after.

"Bruce, if you are so smart, why don't you do it?"

Because I'm not THAT smart ... I am not up to speed on ca65, my projects are in acme.

Edited by BruceMcF
Link to comment
Share on other sites

8 hours ago, BruceMcF said:

Ah, I found it, it's not the Bank, it's the VRAM, where SA=2-17 are the high four bits of a VRAM.

So bits %0001111 of the SA are already allocated by LOAD, so a bit to say "this is headerless" would have to be (header SA)+32 (or +64 or +128), and if bit5 is set, the load is headerless: a SA=32 load goes where set in XY, a headerless SA=34-49 load takes the lower sixteen bits from X/Y, and a secondary address of 33 should go to $A000.

I don't exactly understand. Looking at the kernal source for LOAD, I can tell that the current code only cares whether SA = 0; no other bits are tested. The VRAM bank selection is performed using the A register, which selects only the highest bit, not the highest four.

Link to comment
Share on other sites

Posted (edited)
1 hour ago, Elektron72 said:

I don't exactly understand. Looking at the kernal source for LOAD, I can tell that the current code only cares whether SA = 0; no other bits are tested. The VRAM bank selection is performed using the A register, which selects only the highest bit, not the highest four.

Then the Basic is playing games with the secondary address rather than handing it straight to the Kernel. In the C64, what it says is SA in the Basic is what is fed to the SA in the KERNAL SETLFS call preceding KERNAL LOAD.
 

Quote

LOAD into VRAM

In BASIC, the contents of files can be directly loaded into VRAM with the LOAD statement. When a secondary address greater than one is used, the KERNAL will now load the file into the VERA's VRAM address space. The first two bytes of the file are used as lower 16 bits of the address. The upper 4 bits are (SA-2) & 0x0ff where SA is the secondary address.

So it sounds like rather than feed the SA straight across and the Kernel handling it, Basic is playing games with the secondary address to access the Kernel protocol, which is different. IIRC the protocol was described as being specified to avoid being locked into an FPGA with an embedded 128K Static RAM if there is a later revision that has more available, so that specification allows for four high bits of Vera RAM addressing, where only one bit is needed at present. So they are taking the A register value, which is 0=load, 1-255=verify, and presumably (unless the "upper 4 bits" is removed from the spec) "reserving" three additional bits, but for now it is A=$00, Memory Load, A=$01-$7F, Verify, A=$80, VRAM load.

To be clear, I'm not complaining, it's more convenient to have that in A in the LOAD.

That actually makes it simpler, at the Kernel level, since the bit can be in A in the LOAD call rather than in the SA. Presuming b7=Vera Bank, b4-b6 reserved for future expansion, then b3=SkipHeader. Set a status byte, clear the bit in A and continue with the existing code, then go ahead with the changes as described before.
 

Edited by BruceMcF
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use