Keyboard

[gyurco]

Just two small patches:

• Why don't use the right shift for caps, also, like on the +keyboards.
• Some games only has Sinclair joy opt, or just redefinable keys, so use the second joy port as a Sinclair one (DK'Tronics had a similar interface, one Kempston, one Sinclair, just it had a bug, the up and down directions were reversed on the Sinclair port).

[sorgelig]

Ok. I've just made a shortcut for joystick 1 connection.

One issue i've found after your tape tweaks: border gets messed after tape loading.

[gyurco]

Thanks for merging. Strange, I didn't notice it. In what game/demo do you see the messed up border? I can check it on a real DivMMC, it uses the same tape trap address.

[sorgelig]

any game/demo. It exists from tape loading with white border. It stays white til game/demo change it explicitly.

[gyurco]

If it is not caused by the changed ROM routine at 05CAh by the turbo-loader, then I don't see how can it happen. But will take a look when I get home.

[sorgelig]

Older hook didn't change the border color - i'm 100% sure. Probably, that's why i've used other hook address. It was long time ago and i cannot remember the details already. Since you are busy with ZX core now, you should be familiar to code already, so I can give you a hint for workaround: Spectrum itself cannot read the border color, but core can. So, probably it will be sufficient to store the border color before it enters into loader and then restore it when it finished.

[sorgelig]

Or simply prevent border color change while in loader code.

[gyurco]

I would vote for the second option, but have to see first why it is not changed back :) (LOAD "" changes to border to white, but after finishes, changes back to the original value). I'm debugging in an emulator, where it is changing back.

I think you used the other hook address, since it is the official entry point. However lots of loaders don't use that (that's why the DivIDE was designed with the other hook address).

[sorgelig]

Border color cannot be read back. So spectrum rom routine cannot restore the border. It only can copy value from some official copy of border register which is not always the same.

[gyurco]

Yepp, I know, it is in BORDCR system variable (23624). So it is really strange, since I don't see any relation to its use in the changed entry point.

[gyurco]

Easy to test: 10 BORDER 4 20 LOAD "" 30 PAUSE 0

When it waits for the tape at line 20, the border changes to white, but if you press break, it will change back to green.

[gyurco]

...or after a successful loading, too, maybe it is better to use LOAD "" CODE 16384,6912, to load a screen.

[gyurco]

Did a simple assembly test, in an emulator:

:: LD A,4 OUT (254),A #Makes the border color green ; LD A,32 ; LD (23624),A #BORDCR = border color * 8 LD A,255 LD IX,6912 LD DE,16384 SCF CALL #556 #Loads a screen L1 JR L1

And guess, what color the border ends with? White! And if I uncomment the BORDCR setting, it will end up in green. Will use this to test the core.

[sorgelig]

yeah, that's how it should work. There is no way to restore the color if copy is not filled. Original hook prevented any write to border register.

[gyurco]

Ah, I wasn't aware of that piece of code:

wire ula_we = ~addr[0] & ~(tape_turbo | nIORQ) & ~nWR & nM1;

And the write prevention is still there, however it happens after the original ROM code already changed the border to white (at 55Ah, but the write prevention only kicks in at 562h now, not at 556h). But the question is: do you think it is really needed? I think the original machine's behavior should be replicated. Maybe there will be wild border effects during turbo loading without this?

[sorgelig]

Turbo load is not the same as fast load where loading is done through audio input on 56MHz speed. Turbo load is direct byte injection and doesn't comply to real hardware, so there won't be any border effects during Turbo load. You can create another signal which will prevent writes from required range of addresses and use it instead of tape_turbo signal.

[gyurco]

I am just wondering what is the benefit of having the border writes disabled. If this prevention is removed completely, the result will be different from the real machine? Now the only write is the "set to white", which is on the real hw. Now I think the real problem is that the port write prevention still active when the ROM wants to restore the border colour (it is in the routine at address 53fh), and turbo is disabled only when (addr < 'h53F). If we just remove the write prevention, the result will be a white border during turbo loading, which will be restored after the loading. If I understand your intention, you wanted to avoid this "white flashing" in the border?

[sorgelig]

Well.. It's up to you. If you don't want to change it, then it's ok. May be later i will fix it by myself. I'm just busy by other project.

[gyurco]

I'll do something about it, since it is now half-baked, the "whitening" happens, but the restoring is not. Just would like to know if you prefer to have the border writes disabled during turbo loading, or is it ok to remove the prevention at all.

It would be easy to write wire ula_we = ~addr[0] & ~nIORQ & ~nWR & nM1; instead of wire ula_we = ~addr[0] & ~(tape_turbo | nIORQ) & ~nWR & nM1;

The other fix is a bit more complicated (what you suggested).

[sorgelig]

need to test how it will behave with all-time write enable.

[gyurco]

Yepp, if some will get epileptic shocks from the flashing white border during loading titles with lots of blocks, then the border changes must be prevented :)

[sorgelig]

With always enabled is better. Border flashes, but at least it restores original color and doesn't wait for game to update the border. But original plan was to disable border writes during turbo load.

[gyurco]

I'll send a pull request. Btw, loaders which uses the alternate hook address, and not the official one just skips the border color change code to white and back. I guess they do it for a purpose.