RC2014 - support for TMS9918A video in CP/M subtype

[feilipu]

A TMS9918A video card has been built by @jblang.

He has tested it using the Coleco Adam subtype in the CP/M target classic library, and it works fine.

Would it be possible to link the classic library video drivers for the TMS9918A to the RC2014 target in new library?

[suborb]

There's a problem with the Adam library in that the TMS9918A interrupt is tied to the NMI on that hardware. Which lands in the middle of I think an FCB block.

Working without files is one possibility, but the library probably needs an option to disable enabling the interrupt.

And on the RC2014 case it really ought to just use im1 rather than NMI.

We've done a lot of inclusion of newlib in classic, but not the other way round. The cheap way would be just to create an rc2014_tms9918 library from the classic side and then use that from newlib.

The proper way is probably to migrate all the TMS9918 code to newlib, create the C wrappers and then pull it into classic.

[feilipu]

I was hoping that it could be included from new library, but it sounds like that’s off the table. So replicating the code sounds like the only solution.

The RC2014 only has one interrupt, and that is taken by the serial card, either ACIA or SIO, and chaining is not an option with standard bus hardware. The NMI is not available on the standard bus, only on the Pro bus version.

Can the TMS9918A work without an interrupt? If so, then that would make things much simpler from both hardware and software perspective.

Anyway, I’d hope to add audio shortly, so perhaps that will set a framework...

[jblang]

It depends what you're trying to do. If you're just plotting a static image, you don't need it. If you need to do some animation where the screen updates at a fixed interval, then you need the interrupt. The interrupt, if enabled, triggers on vblank, so you can redraw the screen. For the north american version of the chip I use in my card, this is 60 times a second. All of the z88dk graphics demos I looked at fall into the static category. The clock is the only demo I saw that updates the screen and it looks like it uses a delay loop instead of an interrupt. It is possible to animate things without interrupts, but since it won't be synced with vertical refresh, you may get tearing.

[feilipu]

Then copying a driver that doesn't use the interrupt sounds like a viable solution, at least for the first pass. 👍

IMHO a bit of tearing is far more preferable than needing to build additional hardware and require rewriting all the other drivers to be aware of the potential existence of a video card, that is optional hardware.

[maccasoft]

If you need to do some animation where the screen updates at a fixed interval, then you need the interrupt.

Just a note, frame sync can be obtained also by polling the status register and testing the interrupt flag bit, even if the interrupts are disabled.

[feilipu]

I'm intending to help @jblang to turn his existing TMS9918 library into a 3rd party library (installable with z88dk-lib) shortly. Once that is working for the RC2014, then it could be a basis for integrating, too.

[suborb]

I was just thinking about this the other day - the classic library driver is now separated into libsrc/video/tms9918 and hopefully re-usable. It probably needs a bit of a cleanup still: there's a few bits of code that look like they're MSX bios workarounds.

Anyway, the linked library will cause issues (probably not on RC2014) in that the VBI interrupt isn't disabled during writing to the VDP. The reading of the VDP status register in the interrupt affects the registers with the result that graphical glitching occurs.

[feilipu]

I've recently done a PR to help get his library prepared for the z88dk-lib tool. It needs to be tested before adding SCCZ80 and SDCC fastcall support.

I've had a look and the tms9918 library looks very complete. Is there a way to swing it over into for any newlib target (but specifically RC2014 in first instance) to access?

[zx70]

I recently resolved a good number of bugs in the classic mono gfx lib which crept in with this last relevant evolution. A good part of the demos is now back in working order and probably valid on an higher number of targets.

[feilipu]

I'll close this, aged out.