Locomotive Shell 1.0 - Extending & Modifying Locomotive BASIC

[ZorrO]

I don't know what you are doing here, but maybe you have a problem with inks because they are at a different address in 464 and 6128.

IF PEEK(&BB5B)=0 THEN p=45530 ELSE p=47061 'this check inks address for 464 or 6128

[zhulien]

I don't know what you are doing here, but maybe you have a problem with inks because they are at a different address in 464 and 6128.

IF PEEK(&BB5B)=0 THEN p=45530 ELSE p=47061 'this check inks address for 464 or 6128

It is a recompilation of the OS ROM to be split into two ROMs for further space and possible enhancements.  If all in a single ROM, the interrupt will work, but if in an upper ROM, it will be extremely difficult because interrupts aren't always disabled when upper ROMs are executing, so I moved the interrupt handler to the lower ROM, but... still the hardware colours are mucked up with the ink command.  it's a bit bizzare - but most definitely due to me know knowing exactly how the inks work.  I have built 2 versions, one where entry points are in a single large jumpblock and another where all known official entry points are at their original positions within the lower ROM - although the single jumpblock is cleaner and makes newly added code a lot nicer, i was hoping the original entry locations (if other code jumps to ROMs directly) would increase compatability - but doesn't appear to make much difference.

The 2 main problems I haven't resolved so far is:

- the ink issue, submit an ink command and chances are your text will disappear or be the wrong colour, but it is the correct colour upon reset (note: i did disable the interrupt handler for now to at least get 1 set of inks to work, but no luck yet)
- then figure out why some software breaks and others don't.  Of the ones that don't break, I am surprised: discology 6 for example, then others that do break, CP/M 2.2/Plus (not sure why yet, unless they do extensive jumps to undocumented locations in the lower ROM).

[andycadley]

It's worth noting that the INK command doesn't directly set the ink, it just sets the relevant values for the interrupt handler to actually set the hardware colours at the next flyback.

So if the INK command isn't aware of where you've moved the data to, or the interrupt handler is looking in the wrong place, you'll get unexpected colours. Disabling the interrupt won't help, because it just means the colour values never actually get configured.

[McArti0]

https://cpctech.cpc-live.com/docs/os.asm

Code Select Expand

OS-LowROM 6128
0d87 11e5b7    ld      de,$b7e5  'hard address palette 1
0d8a 3af6b7    ld      a,($b7f6)
0d8d b7        or      a
0d8e 3ad3b7    ld      a,($b7d3)
0d91 c8        ret     z
;;===========================================================================
0d92 11d4b7    ld      de,$b7d4  'hard address palette 2
0d95 3ad2b7    ld      a,($b7d2)
0d98 c9        ret

[Bread80]

trigger the switch between sets

do you know how to check which set is currently loaded? I tried to follow this interrupt but got lost several times and failed.

I've had a dig in the source code, and updated the firmware variables list at https://github.com/Bread80/CPC6128-Firmware-Source/blob/main/Includes/MemoryFirmware.txt

On a '6128 you need the byte at &b7f6. It should be &00 if the first set of inks is active, &ff for the second.
&b7f8 is the current value of the counter (counts down).

For '464 and other related addresses check the link