Finally new graphic mode for Lambda 8300

[mrtinb]

Some of you have seen DrBeep's new software hack to add graphics in text mode on the ZX81.

I have tried the same program on the Lambda 8300, to see if we can have custom graphics on the Lambda 8300. This is more exiting than on the ZX81 that already supports both Pseudo Graphics and maybe WRX graphics. The Lambda 8300 does not support these graphics modes, so we are stuck with text mode.

A demo program have be posted in Basic here:

viewtopic.php?p=55460#p55460

I have changed line 90 to this, as the D-file is different on the Lambda 8300.

Code: Select all

90 LET M=16509

The new graphics is called QuaracterDisplay Graphics (maybe QDG). It takes line 1 & 2 from 1st char, 3 & 4 from 2nd char, 5 & 6 from 3rd char and 7 & 8 from 4th char. This does not give us hires graphics but more like a Limited User Defined Graphics (UDG).

I have tried this on 2 Lambda 8300 emulators, and on real Lambda 8300 hardware.

1. First I tested with the emulator NO$ZX 2.0. The output is shown in the left part of the image. This emulator does not support this trick at all.
2. Next I tested the program with the EightyOne emulator. The output in shown in the middle of the image. This displays the code as on the ZX81.
3. But the most important is to see if this will work on real hardware. The output is shown i the right of the image. Here we have the code running on a real Lambda 8300.

Conclusion:

• Neither of the emulators NO$ZX or EightyOne emulates the Lambda 8300 correctly here.
• It is FINALLY possible to display some graphics on the Lambda 8300. We are no longer limited to text mode.
• The ROM routine to display the text mode characters on the Lambda 8300 is different, thus the output is not the same as on the ZX81. From the output I assume the Lambda 8300 takes line 1 & 2 from line 2 & 3 of the 1st char, 3 & 4 from the line 4 & 5 from the 2nd char, 5 & 6 from line 6 & 7 from the 3rd char, line 7 from line 8 from the 4th char, and line 8 we still not know where it comes from, but probably the 1st line of the next char in the alphabet.

This is a GREAT discovery, as we now can try to code som new graphics on the Lambda 8300.

[dr beep]

Thanks for trying.

The first emulators work a bit like my ZX81 emulator on the ZX Spectrum.
However... I used this method to gain some speed which is needed for emulation on the ZX Spectrum.
At the moment I am thinking how I can add this display without losing too much speed in the emulation.

As for the real hardware..... we need to figure out how the hardware handles the reading. Perhaps you must place the LD H,D and LD L,E at the end of the line. I will try finding out why it could do something else although I was expecting the display as on EightyOne.

[dr beep]

If somehow the first line is displayed double then it explains the shifting in the graphic.

Can you add a normal text line below the graphic? Preferably one with a character that fills 8 lines (like character 8 on the ZX81).

And on the first line 1 character inverted to see how many lines between the next display.

[dr beep]

Try adding a character 118 at the start. The demo might start POKING on the ZX81 after the first linefeed.

So LET T$=CHR$ 118+"THIS IS A TELEPHONE" +CHR$ 118 + rest

[mrtinb]

Hi.

So I've added a line after, and then it seems to work. I forgot the 118 extra on the first line.

[dr beep]

Great,

seeing the display I figured out it had to be that first linefeed.
You must not POKE over the first linefeed of the DFILE or start with a linefeed if you do.

BTW I just played a bit with the 8linedsplay and I will show the easiest way to do that. I figured out just now.

[mrtinb]

You must not POKE over the first linefeed of the DFILE or start with a linefeed if you do.

I can't see how I overwrite the first 118, as line 110 pokes M+A. M is 16509 (which is the first byte), but A is 1, so the poke will go to 16510.

[dr beep]

You must not POKE over the first linefeed of the DFILE or start with a linefeed if you do.

I can't see how I overwrite the first 118, as line 110 pokes M+A. M is 16509 (which is the first byte), but A is 1, so the poke will go to 16510.

I can't see what you changed to the first program since that was not displayed. However my suggestion was right.

[1024MAK]

Some great work there guys

Mark

[dr beep]

Not a problem, but the REM has an error. It is LD H,D not LD H,L