LM80C

Discussion about other targets
Post Reply
nippur72
Member
Posts: 29
Joined: Sat Sep 29, 2018 4:47 pm

LM80C

Post by nippur72 »

(This thread for discussing the progress of the implementation of LM80C in Z88DK)

I updated the online emulator:
- fixed the problem that caused the forever loop (at least I think so, if you continue to experience it please let me know)
- is is now possible to select the firmware ROM to boot from (V3.xx). Add "rom=" query string parameter to the url, e.g.

https://nippur72.github.io/lm80c-emu/?rom=315

the default is 3.14 which is the one that is compatible with the current Z88DK implementation.

BTW, when a ROM gets updated the emulator needs to be updated with the following pointers:

Code: Select all

// firmware 3.14
let BASTXT     = 0x8133;    // points to basic free area (start of program)
let PROGND     = 0x81BB;    // points to end of the basic program
let CRSR_STATE = 0x81E9;    // cursor visibility state (for injecting keys)
they are needed to inject the program in RAM and then send the "RUN" command. At the moment they are fixed, but I can modify them so to get aligned with the firmware (now that 3.15 is out).

Currently I have the following issue: I wrote a small "hello world" program which doesn't printf() anything unless I substitute "fputc_console" with my own. I tried to trace back what is the actual fputc_console that is included but was not able to figure it out (due my poor understanding of Z88DK).

Is there any test program to run on the LM80C to test the various features so to check that they are correctly implemented?
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: LM80C

Post by dom »

Thanks for the emulator change - I'll test it out later.

When I added the target I deliberately chose not call into the ROM, it just felt like the entry points might change since they weren't tied into rst addresses.

In terms of screen output I implemented the generic console which is the default, however it doesn't switch VDP mode on startup, so you need to add the following lines:

Code: Select all

   int mode = 2;
   console_ioctl(IOCTL_GENCON_SET_MODE, &mode); 
I think I added a way to prime the library to match the machine mode, so if there's a convenient system variable with the VDP mode in, I should be able to make it work transparently.

In terms of test programs, I've got a bunch of them but I've not added them to the repo since they're full of little hacks to cope with targets as I bring them up so I'm a bit ashamed of them!
nippur72
Member
Posts: 29
Joined: Sat Sep 29, 2018 4:47 pm

Re: LM80C

Post by nippur72 »

ok thanks, I tried it and it works:

Code: Select all

#include <stdio.h>
#include <sys/ioctl.h>

void main()
{
  int mode = 2;
  console_ioctl(IOCTL_GENCON_SET_MODE, &mode);

  printf("hello\r\n");
}
Immagine.png
You do not have the required permissions to view the files attached to this post.
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Re: LM80C

Post by RobertK »

dom wrote: Tue Dec 08, 2020 11:40 am In terms of screen output I implemented the generic console which is the default, however it doesn't switch VDP mode on startup, so you need to add the following lines:

Code: Select all

   int mode = 2;
   console_ioctl(IOCTL_GENCON_SET_MODE, &mode); 
Please add this information to the wiki target page.

Now it works for me too, thanks!

HTron_LM80C.jpg
You do not have the required permissions to view the files attached to this post.
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: LM80C

Post by dom »

I have to admit I didn't really consider the target finished since I've not added support for <input.h> - hence the GitHub issue being open and no announcement!

However, it looks like the target has been made public now, so, I'd better update the wiki! :)
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Re: LM80C

Post by RobertK »

Attached is a WIP package of my three programs for the LM80C. Everything is already working fine, only keyboard input is problematic.

H-Tron: this is perfectly playable, but often (after two or three rounds) the keyboard gets blocked and you need to restart the emulator. @Nippur72: could this be an emulator issue?

Mastermind RK: keyboard input (here via games.h) is quite lame - interestingly, "down" is more responsive than "up". As with H-Tron, keyboard input sometimes gets entirely blocked.

EPB: same es Mastermind RK, otherwise everything is fine.
You do not have the required permissions to view the files attached to this post.
nippur72
Member
Posts: 29
Joined: Sat Sep 29, 2018 4:47 pm

Re: LM80C

Post by nippur72 »

@RobertK, yes HTron sometimes hangs in the emulator, but I've not identified why yet. Most likely it gets stuck waiting for something to arrive from the keyboard.

I've tested it on the FPGA and it does not hang there--but there is another issue: the graphic is completely corrupted (see the picture below). My first guess is that the program does not access the VDP with the correct timings, as far as I know the TMS9918 needs a certain setting time before you can write to it again. Anyway I didn't expect this behavior to show on the FPGA because the re-implementation of the chip most likely does its job in one clock cycle.

Another strange thing on the FPGA is that the "snake" moved by the CPU is immune to collisions.
Immagine.jpg
You do not have the required permissions to view the files attached to this post.
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: LM80C

Post by dom »

I’ve seen this previously when there’s a conflict between the interrupt servicing the vdp and user code.

Given that it’s shown up I guess the vdp is serviced by the nmi? In which case I’ll need to revector it and implement it as part of the crt.
nippur72
Member
Posts: 29
Joined: Sat Sep 29, 2018 4:47 pm

Re: LM80C

Post by nippur72 »

dom wrote: Wed Dec 09, 2020 6:59 pm I guess the vdp is serviced by the nmi?
in the LM80C the VDP VSYNC pin is connected to the Z80 NMI, so it can trigger an interrupt at the end of each frame; but it's disabled by default when the VDP is initialized at boot.

There is also a BASIC command named "NMI" for setting an interrupt handler routine, but it's not very useful to use it from BASIC as it cause lot of troubles.
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: LM80C

Post by dom »

Now I'm at a proper keyboard I see your point, there's nothing in the NMI handler that could interfere (since it's just retn).

When switching mode, interrupts are turned on though, so I wonder if that's causing problems no the real/fpga hardware?

The timing should be good: I've run the same code on emulators that report timing issues, and as you hinted, an FPGA implementation probably doesn't have the issue.

Looking at the ROM disassembly, the issue might be the 0.01s tick - it looks like the cursor flash is hooked into this.

So, I've pushed some changes that if you don't mind trying out:

1. The NMI is hooked and the VDP status is cleared
2. The cursor is disabled on startup

Hopefully one of them will sort the problem out on the "real" hardware.
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Re: LM80C

Post by RobertK »

I had already seen this problem two years ago on my MSX computer, a Philips VG-8020. Some time later I decided to report it on the forum, and when I had set up my MSX to make better photos, the problem was gone. I wasn't sure whether I had re-compiled my game between these two attempts, so I thought that the issue had been fixed in z88dk.

The problem was/is also there on an FPGA implementation of the ColecoVision, another TMS9918 machine, shown in the third photo on the ZX-Uno. And on the MiST the problem is also present, but I believe both these cores are based on the same FPGA VHDL source.

So here are my photos that I took two years ago.

The intro screen of H-Tron is missing its left border, I have not seen this with any other MSX program on this machine:
MSX_03.jpg
And here the same problem as shown by nippur72, collision detection isn't working either:
MSX_02.jpg
And here the same problem on the Colecovision in FPGA running on a ZX-Uno (ignore the missing left border, that's a problem of this TV set).
MSX_04.jpg
You do not have the required permissions to view the files attached to this post.
Last edited by RobertK on Fri Dec 11, 2020 8:55 am, edited 1 time in total.
nippur72
Member
Posts: 29
Joined: Sat Sep 29, 2018 4:47 pm

Re: LM80C

Post by nippur72 »

RobertK wrote: Thu Dec 10, 2020 10:41 pm The problem was/is also there on an FPGA implementation of the ColecoVision, another TMS9918 machine, here shown on the ZX-Uno. And on the MiST the problem is also present, but I believe both these cores are based on the same FPGA VHDL source.
you are right, the there is actually one FPGA implementation of the TMS9918 that is shared among the various targets and FPGA platforms, so an issue in it will manifest in all of those.

Regarding the left border, I spent a lot of time trying to understand why that happens, I checked and rechecked the TMS9918 timings on the FPGA (HSYNC, VSYNC, back and front porch etc...) and they are all ok, they perfectly match the datasheet. So I don't know why CRT displays pick it that way... I wonder how a real TMS9918 looks like (I don't have a real machine to check it myself). In the LM80C fpga I added a sort of converter that takes the signal from the TMS9918 and shifts the image to the right so that the border isn't cut; but a piece of the 32nd column on the right is trimmed out.
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: LM80C

Post by dom »

I've just played around with plotting in Emulicious that allows a breakpoint on VDP timing issues.

It looks like the pixel manipulation routines did violate timing, so I've slowed them down a bit. Hopefully this will also fix the FPGA problems.
nippur72
Member
Posts: 29
Joined: Sat Sep 29, 2018 4:47 pm

Re: LM80C

Post by nippur72 »

It does! I compiled HTRON with the nightly build and it works perfectly on the FPGA. It's amazing to see that even side effects are emulated :-)

It still hangs in the emulator though, I haven't had the time to debug what's wrong yet.
nippur72
Member
Posts: 29
Joined: Sat Sep 29, 2018 4:47 pm

Re: LM80C

Post by nippur72 »

For those who want to compile for a different firmware EPROM version of the system, I wrote a small script (windows batch file) that allows you to use a parametric version of the ".asm" files where the symbols that change are passed with a -pragma-export directive.

Here's the repo: https://github.com/nippur72/z88dk-lm80c-firmwares

I've made the BASIC header ("2020 SYS&H8241:END") adapt itself to the changing address. There's lot of math involved, is there a better way to do that in z80asm ?

I've also changed "fputc_console" to use the ROM routine, because I like to make it print directly on the boot screen without setting the console mode (just my taste).

BTW, I tried to define the symbols with "DEFC" instead of "-pragma-export", but for some reason it didn't work.
nippur72
Member
Posts: 29
Joined: Sat Sep 29, 2018 4:47 pm

Re: LM80C

Post by nippur72 »

this is how I made the "2020 SYS &H8241" self relocating:

Code: Select all

        defc SYS_ADDRESS = CRT_ORG_CODE+16

        defc SYS_DIGIT1 = ((SYS_ADDRESS & 0xF000) / 256 / 16)
        defc SYS_DIGIT2 = ((SYS_ADDRESS & 0x0F00) / 256     )
        defc SYS_DIGIT3 = ((SYS_ADDRESS & 0x00F0) / 16      )
        defc SYS_DIGIT4 = ((SYS_ADDRESS & 0x000F)           )

        defc SYS_HEXDIGIT1 = ((SYS_DIGIT1+48)*(SYS_DIGIT1 <= 9)) + ((SYS_DIGIT1+65-10)*(SYS_DIGIT1 > 9))
        defc SYS_HEXDIGIT2 = ((SYS_DIGIT2+48)*(SYS_DIGIT2 <= 9)) + ((SYS_DIGIT2+65-10)*(SYS_DIGIT2 > 9))
        defc SYS_HEXDIGIT3 = ((SYS_DIGIT3+48)*(SYS_DIGIT3 <= 9)) + ((SYS_DIGIT3+65-10)*(SYS_DIGIT3 > 9))
        defc SYS_HEXDIGIT4 = ((SYS_DIGIT4+48)*(SYS_DIGIT4 <= 9)) + ((SYS_DIGIT4+65-10)*(SYS_DIGIT4 > 9))
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: LM80C

Post by dom »

Ah cool, that's one solution to the evolving ROM I guess - I do wish there was a jump table! I think I was going to add the native print routines but felt a bit blocked by changing addresses.

Do you mind if I take it and bake it into the config files? I think we can do a -subtype=firmwareXXX options to do it all in one go.

I don't think z80asm has got a stringify feature actually, however if the lm80c_crt0.asm is renamed to lm80c_crt0.asm.m4 then m4 can preprocess it and you can use m4 features to achieve what you want.
nippur72
Member
Posts: 29
Joined: Sat Sep 29, 2018 4:47 pm

Re: LM80C

Post by nippur72 »

yes of course take what is needed -- unfortunately I am not acquainted enough with z88dk's repo to push a PR myself... Z88DK is huge and scary! But if you add them as subtypes I think I can manage to write a PR when a new firmware release is out.

Regarding to CRT0, in my version I removed the NMI handler which is a feature not used in the LM80C (it has issues) and I removed also the CURSOR_STATE turn off, because the RUN command already does it.
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: LM80C

Post by dom »

nippur72 wrote: Fri Jan 22, 2021 4:15 pmRegarding to CRT0, in my version I removed the NMI handler which is a feature not used in the LM80C (it has issues)
I know there's a 0.01 second tick, but is there another way to synchronise with the VDP?
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: LM80C

Post by dom »

nippur72 wrote: Fri Jan 22, 2021 4:15 pm yes of course take what is needed -- unfortunately I am not acquainted enough with z88dk's repo to push a PR myself... Z88DK is huge and scary! But if you add them as subtypes I think I can manage to write a PR when a new firmware release is out.
There's a lot of code, but after all this time it's a bit like lego at times!

I chose -clib= as the option for switching between firmware versions, this keeps it consistent with other targets and also allows space for supporting discs/roms if they become available: https://github.com/z88dk/z88dk/blob/mas ... /lm80c.cfg

The option just sets a define which is then picked up by lm80c.def which has a section for each firmware: https://github.com/z88dk/z88dk/blob/mas ... /lm80c.def - that file is included by lm80c_crt0.asm so the symbols are available link time.

This should make it easy to add support for new firmware versions.

I've also defaulted the target to use the firmware printing by default and additionally slowed down keyboard handling so that typing is possible.
nippur72
Member
Posts: 29
Joined: Sat Sep 29, 2018 4:47 pm

Re: LM80C

Post by nippur72 »

Great, thanks! that makes things lot easier.
Post Reply