Intel 8275 unitialized behaviour not emulated

[RetroAND]

MAME version

mame0272-367-g8907baff125-dirty

System information

Not required for this issue

INI configuration details

No response

Emulated system/software

IBM System/23 Datamaster

Incorrect behaviour

I am writing a driver for the foresaid computer but it gets stuck in a test because the implementation of the Intel 8275 is incomplete. The current behaviour makes the device do nothing. This means that the counters are not enabled and therefore an interrupt cannot be generated.

Expected behaviour

The counters should be running at random timings before the reset command is issued. This way the interrupt would get generated and the test would succeed.

Steps to reproduce

Issue the the enable interrupt command to the CRTC without issuing the reset device command beforehand. Then loop reading the status register of the 8275 until the interrupt request flag is set.

Additional details

This error was found during development of a driver that will be added but the issue is within the libraries of emulated video devices.

[angelosa]

As per also reading https://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=124049#Post124049 , the root problem is that screen_device doesn't have a way to define floating beamx / beamy, and, by chain reaction, h/vsync signals. It starts and it never stops unless user hijacks with reset_origin() or other misc hacks like machine/smpc.cpp or snk/hng64_v.cpp

This is obviously a legacy short-sight which roots back to #5801

[RetroAND]

Actually I was able to solve the issue by initializing the internal registers of the 8275 with valid data at device_start.

[angelosa]

That's not solving, that's working around the problem :)

[RetroAND]

Unfortunately I am not knowledgeable enough to resolve the root of the issue, do you mind if I PR the modified i8275.cpp in order to make it work?

[pmackinlay]

Given the response prior, that PR will likely not be accepted, however I suggest you keep it as a local workaround in your tree so you can progress on other work until you find a more correct solution.

[startaq]

I don't think there is anything wrong with the solution, this is independent from any screen_device shenanigans. The chip is powered up with random values and starts counting and this is what the PR would presumably implement.

[RetroAND]

The only difference with the real hardware is that I was told to use valid data instead of random or dummy values. So They passed me an Intel Application Note and extracted the values from there.

[cracyc]

I think it's fine as long as it doesn't break anything else.

[RetroAND]

Okay. I will PR it, but the PR includes the unfinished driver. Should I wait until the driver is more complete and cancel the current PR or fix the 8275 asap?

[cuavas]

Taking a step back, has anyone else debugged this as a sanity check? It seems rather odd, particularly for sticklers for rules like IBM. Not programming the CRTC before POST is liable to fry the monitor.

[RetroAND]

This computer checks first if the data bus is in conditions (test 00) by writing and reading to a 8255. Then checks the CPU itself and also the state of the SID line (test 01). Then performs CRC checks to the boot ROM (test 02). Test 03 does not exist, as the number is skipped. The first 16KB of RAM are checked in three different ways and an input port is read (test 04). The 8275 is detected by checking its interrupt flag, then the CRT is activated and both 8275 and 8257 are initialized, for some reason after that it seeks for a light pen (all of this test 05). Before test 07 the test number has to be checked with a probe which can be as simple as eight LEDs.

[cuavas]

Doesn’t answer the question – has anyone else debugged this as a sanity check?

[angelosa]

It's currently in PR #13191 so no most likely.

This computer checks first if the data bus is in conditions (test 00) by writing and reading to a 8255.

Port C by any chance? Perhaps expecting a Power On Reset bit high from there?

[RetroAND]

No, it's port A from the same 8255 that manages the keyboard. No, it does not expect a special bit from there, just reads and wites back from the register. I have seen it being used also in test 05, so I suspect that it also has some video-related usage.

[RetroAND]

Continuing the development of the driver found another issue (not me, but Golden Child at bannister) where GPA0 and GPA1 attributes were lost in certain cases. There may be other issues in the light pen section as well.

As a result I will withdraw my PR until both the component controller and the driver are more mature.