(classic) New target: Lviv/Lvov PK-01

Discussion about other targets
Post Reply
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

(classic) New target: Lviv/Lvov PK-01

Post by dom »

Most of the code for this machine has been committed for a few months, however I've finally written a keyboard reader, so it's now good enough to be announced.

This one is a Ukranian machine with an almost unheard of production run of 80k machines - mainly into educational settings.

Specs are:

* KR580VM80A at about 2Mhz
* 48kb of RAM
* 16kb of ROM containing a bootleg Microsoft BASIC
* 16kb of VRAM providing a 256x256 pixel display with 2bpp

If, like me, you find that you can't get your fingers around the JCUKEN keyboard there's an option to switch the keyboard map to qwerty which will probably make things a bit easier on emulators.

The wiki page is here: https://github.com/z88dk/z88dk/wiki/Platform---Lviv
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Re: (classic) New target: Lviv/Lvov PK-01

Post by RobertK »

Thanks for this new target! A few issues:

1. There seems to be some bug with c_plot(), compile my plottest.c program with

zcc +lviv -create-app -pragma-redirect:fputc_cons=fputc_cons_generic -pragma-redirect:in_keytranstbl=in_keytranstbl_qwerty -o plottest_LVIVPK01_QWERTY plottest.c

and you will see that the c_plot() pixels all end up in a tiny top-left portion of the screen.

2. The default fore colour is orange, it seems that white isn't available in four-colour mode. But wouldn't green be a better choice? The orange colour is quite dark and hard to read on black background.

3. The wiki mentions "16k VRAM giving 256x256 2bpp resolution screen with 4/16 colours". How do we get these 16 colours, maybe by switching sceen modes (which are not yet documented on the wiki)?

4. Is there already Math library support for this target, and if so, shall we use -lm or --math-mbf32_8080? I couldn't get it working yet in EPB.
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: (classic) New target: Lviv/Lvov PK-01

Post by dom »

RobertK wrote: Sun Feb 07, 2021 9:49 am Thanks for this new target! A few issues:

1. There seems to be some bug with c_plot(), compile my plottest.c program with
This must be the first 8080 target with a display < 256 pixels! That one should be fixed now.
2. The default fore colour is orange, it seems that white isn't available in four-colour mode. But wouldn't green be a better choice? The orange colour is quite dark and hard to read on black background.
I haven't done the colour mapping yet, to be honest I've yet to decipher the palette control: https://github.com/mamedev/mame/blob/ma ... v.cpp#L161 - hopefully we'll be able to set it so we get some sensible colours.

That's interesting with the orange - personally I find it much more readable than the green! But then again, that's probably my deuteranopia.
4. Is there already Math library support for this target, and if so, shall we use -lm or --math-mbf32_8080? I couldn't get it working yet in EPB.
DAI32 and mbf32_8080 should work.
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Re: (classic) New target: Lviv/Lvov PK-01

Post by RobertK »

I normally prefer amber monochrome screen over green ones, but here the orange text is IMHO quite dark and therefore difficult to read. There could be a reason why this system by default uses green on black colour for text output.

Thanks for the c_plot() fix, I will check it tomorrow.

I've noticed that there seems to be some floating point problem, here is my little floatcalctest.c program:

Code: Select all

// Floating point calculation test
// Author: RobertK, 2018-12-29

// Compile with:
// zcc +gal -create-app -lm -o fct floatcalctest.c
// zcc +zx81 -create-app -lm -startup=2 -o fct_zx81 floatcalctest.c
// zcc +zx80 -create-app -lm -o fct_zx80 floatcalctest.c
// zcc +gb -create-app -lm -o fctgb.gb floatcalctest.c
// zcc +pmd85 -create-app -lm -o fctpmd85.gb floatcalctest.c

// zcc +lviv -create-app --math-mbf32_8080 -pragma-redirect:fputc_cons=fputc_cons_generic -pragma-redirect:in_keytranstbl=in_keytranstbl_qwerty -o fct_LVIVPK01_QWERTY floatcalctest.c
// or
// zcc +lviv -create-app --math-dai32 -pragma-redirect:fputc_cons=fputc_cons_generic -pragma-redirect:in_keytranstbl=in_keytranstbl_qwerty -o fct_LVIVPK01_QWERTY floatcalctest.c

#include <stdio.h>

void main()
{   

  // Clear the screen
  printf("%c",12);
  printf("\x0c");  // the "\x0c" (0x0c character) resets the cursor position to the top left corner

  printf("\nhello world\n");
  printf("\npress any key to calculate 5*0.1...\n");
  fgetc_cons();	// wait for keypress	  
  printf("\n5*0.1 is %.1f\n",5*0.1);
  printf("\npress any key to exit...\n");  
  fgetc_cons();	// wait for keypress	  
}
It crashes when performing the 5*0.1 calculation, no matter whether you compile it with

zcc +lviv -create-app --math-mbf32_8080 -pragma-redirect:fputc_cons=fputc_cons_generic -pragma-redirect:in_keytranstbl=in_keytranstbl_qwerty -o fct_LVIVPK01_QWERTY floatcalctest.c
or
zcc +lviv -create-app --math-dai32 -pragma-redirect:fputc_cons=fputc_cons_generic -pragma-redirect:in_keytranstbl=in_keytranstbl_qwerty -o fct_LVIVPK01_QWERTY floatcalctest.c
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: (classic) New target: Lviv/Lvov PK-01

Post by dom »

Hmmm, the section names were wrong so addresses ended up just being wrong.

Now I've fixed that, I get the result 0.6 with PK01 emulator which suggests there's an 8080 flags? emulation issue.

However, I've fixed up the -subtype=snapshot option so that you can load the generated .dump files as a Mame snapshot which does produce the correct result.

I've provided updated mbf libraries for you here: https://www.z88dk.org/misc/mbf_20210207.zip which will work with the build tonight.
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Re: (classic) New target: Lviv/Lvov PK-01

Post by RobertK »

Thanks, the mbf math libraries work fine, and when using --math-mbf32_8080 floatcalctest.c gives the *correct* result 0.5.

I have now released EPB and MastermindRK for the PK-01. H-Tron still needs some work for using the JCUKEN keyboard (games.h virtual joystick input makes all this much easier). The c_plot() problem is fixed now, thanks.

In MastermindRK I will keep colour disabled for this target until 16 colour mode should get available one day.

I haven't been able to load a snapshot in MAME. Should the loaded program start automatically or is any more action required to run it?
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: (classic) New target: Lviv/Lvov PK-01

Post by dom »

That's good. The keyboard kept tripping me up to be honest: I'm not wonderfully happy with the joystick selection but you're right, <games.h> does insulates you from figuring out the underlying hardware.

I'm using 0.217 (probably time for an upgrade?), and it starts automatically with that version.
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Re: (classic) New target: Lviv/Lvov PK-01

Post by RobertK »

I'm using the latest MAMEUI64 0.228, but I have now tried it with MAME 0.216 as well (passing the .dump file with the -snapshot parameter), and the program still didn't start.
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: (classic) New target: Lviv/Lvov PK-01

Post by dom »

...and the difference is....I was using the file menu to load the snapshot and not specifying it on the command line.

So, when I use the command line I end up with a black screen. Looking into it, it appears that the mame snapshot loader doesn't read the palette settings from the snapshot and thus the palette is uninitialised: all black.

However, there's obviously something else going on - writing to the palette port on startup still doesn't fix the problem.
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Re: (classic) New target: Lviv/Lvov PK-01

Post by RobertK »

Hmm, even when I load a .dump snapshot in MameUI 0.228 using the "File manager", nothing happens (no black screen, just nothing).

I have now released H-Tron for the PK-01, and I have included the .dump files in the package, in case that you want to investigate further.

BTW, try loading one of my .lvt files into the PK-1 Lvov emulator while the system is doing its colour cycling test during startup: the program screen will get one of these colour combinations instead of orange on black. But that probably can't happen on the real machine, so it's not really a problem.
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: (classic) New target: Lviv/Lvov PK-01

Post by dom »

Hmmm, that's interesting. Your .dump files are coming out to be 4k. But they should be 82219 bytes long.

Is that an issue with zipping or is it genuinely creating files that are 4k in size?
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Re: (classic) New target: Lviv/Lvov PK-01

Post by RobertK »

dom wrote: Sun Feb 14, 2021 12:29 amYour .dump files are coming out to be 4k. But they should be 82219 bytes long.
Good point! Now I've found out that the -subtype=snapshot compilation is unsuccessful (the 4K .dump files still get created, so until now I thought that everything had gone ok). After my usual tons of warnings it says:

Building application code failed

Try compiling htron.c with compile_htron_lviv.bat, the two .lv compilations work, but the two snapshot ones don't.

BTW, is there an easy way to get rid of these compiler warnings? I think they first appeared one or two years ago when something was changed in z88dk.
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: (classic) New target: Lviv/Lvov PK-01

Post by dom »

The compiler warnings are easy to get rid of:

1. #include <conio.h>
2. Prototype the 4 AICheckDistance functions

I've probably tracked down to truncated file to a silly mistake: oddly I couldn't reproduce the issue but it's the most likely cause.
Post Reply