Commander X16

7 hours ago, Elektron72 said:

Personally, I think it would make more sense to do this using the secondary address, which is already used to tell the load routine whether to ignore the header (SA = 0) or to load to the location it specifies (SA = 1). This would allow a headerless file to be loaded to VRAM without having to add additional flags.

If you test bit2 of that flag, save the result, then clear it, you get headerless load, headerless verify, headerless VRAM bank 1, headerless VRAM bank 2. It's four additional flags from the user side but only one test and one action on the Kernel side.

Though I've forgotten ... what is used to send the RAM bank to load to?

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.

On 5/25/2021 at 2:50 PM, Elektron72 said:

@Snickers11001001 Decided to try cross-compiling R39 for Windows; tell me if this executable works properly.



x16emu.zip 884.29 kB · 4 downloads

I tried it with my "twisted transcendentals" basic demo and it seems to work fine.   Thanks!    That said, seems like its best to hold off on developing specifically for R39 since the repo hasn't been version-frozen yet and an official release may be some time off.   If I were 'inside' the project and official hardware were going to beta-testers soon, I'd delay R39 until the betas were out; and even then, I might call it R39beta or even hold off on another emulator release until after the beta so that feedback from the hardware beta testers could be rolled into the official emulator release.    Any official new release prior to that would generate a flurry of new software development (which means if further tweaks to kernal, etc., were needed due to issues ascertained in beta, then those software writers would be on shifting sand).  It would be entirely reasonable to forestall that in the context of an 'soon' finalization of hardware until the 'official' crowdfund is on with official hardware at which point there could be an emulator release that IS the official hardware, in its 'release' config, or as close as reasonably possible. 

I think its best we all continue to be patient.     

On 5/25/2021 at 2:48 PM, ZeroByte said:

LDX #0

LDA eal

STA (eal),X

LDA eah

STA (eal),X

1. (zp),X isn't a valid addressing mode. You have (zp),Y and (zp) without indexing on 65C02.

2. You never INX (or really, INY) between each STA instruction, resulting in (eal)+0 to be written with eah instead of eal, and (eal)+1 won't be written at all.

Here's my version (compatible with all 65xx systems):

LDY #0

LDA eal

STA (eal),Y

INY

LDA eah

STA (eal),Y

11 hours ago, StinkerB06 said:

1. (zp),X isn't a valid addressing mode. You have (zp),Y and (zp) without indexing on 65C02.

2. You never INX (or really, INY) between each STA instruction, resulting in (eal)+0 to be written with eah instead of eal, and (eal)+1 won't be written at all.



Here's my version (compatible with all 65xx systems):



LDY #0

LDA eal

STA (eal),Y

INY

LDA eah

STA (eal),Y

The fastest 65C02 version of store pointer value to pointer location is only two clocks faster and one byte shorter:

+ LDA eal : STA (eal) : LDA eah : LDY #1 : STA (eal),Y

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.

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.

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.

 

some sort of "workaround" to load headerless files can be this:

OPEN file

CHRIN 2 bytes to the first 2 load locations in memory

CLOSE file

LOAD file in memory location+2

 

I built this into prog8 as load_raw() and it works like a charm, just requires a fair bit of extra code (hidden away in a library)