09076: elf2: Issues that make the system unusable

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
09076	Interface	Critical (emulation)	Always	8 days ago	5 days ago

Tester	Robbbert	View Status	Public	Platform	MAME (Self-compiled)
Assigned To		Resolution	Open	OS	Windows 10/11 (64-bit)
Status [?]	Confirmed			Driver	netronics/elf.cpp
Version	0.273	Fixed in Version		Build	64-bit
		Fixed in Git Commit		Github Pull Request #

Summary	09076: elf2: Issues that make the system unusable
Description	This system is marked as working for years, but to my knowledge it has never worked. 1. The wrong Video Setting is selected by default 2. The 7-segment digits should be on as soon as the machine is started, but they are blank. 3. Not possible to enter any data, thus making it useless. 4. Probably more, but the above makes it impossible to test.
Steps To Reproduce	Start the system: >mame elf2 Firstly, there's a red warning screen, but only because the sound isn't emulated. The original machine doesn't have sound. You get a black screen. This is because the default video is CDP1861, which is not in the original machine. You need to go to Video Options, Screen #0, and choose Standard. Now you get a screen with blacked-out digits. At this stage they should show some random hex numbers. They should never be blank. The machine has 3 toggle switches (L, M, R) but there's no indicators of their state on-screen, so you need to visit the tab menu, Input Settings, Toggle Inputs, and see what it says. The first time run has all 3 switches off, but the current setting gets saved to elf2.cfg on exit, so you need to check the Toggle Inputs each time you run the system. In order to input some data, you need to have LOAD ON, M/P OFF, RUN OFF. Load on permits data entry, M/P off allows writes to RAM. At start, the address is 0000 (it isn't displayed anywhere, you need to memorise it). Now type in 7A, (display shows 0F), hit IN (the 'enter' key) to save the byte to RAM address 0000. The display should now show 7A. The internal counter (register R0) should increment to 0001. However, none of this works. The display is incorrect. The data isn't saved, and the counter doesn't change. Entry of further bytes only shows FF, with nothing else happening.
Additional Information	If you use the debugger to write data to the RAM, it is reflected on the 7-segment displays and saved. R0 does not change though (I don't know if it should via the debugger). I used it to input the standard "Q-led flasher" test program. When R was pressed it ran and the LED flashed. Pressing L paused it, pressing again resumed. So that all works. Next, I input another test program that checks the IN button being pushed, and turns the Q-led on or off in response. This did not work. The Input button does not seem to do anything.
Github Commit

Flags
Regression Version
Affected Sets / Systems	elf2

Attached Files

No.22808 hap Developer 8 days ago	After https://github.com/mamedev/mame/commit/89e38850b15d212c3a6c582172e36b681b5f4245 it says "00" at boot instead of a blank display. I also changed the no sound flag to MACHINE_NO_SOUND_HW. Random device latch state at power-on is something MAME doesn't do. machine().rand() makes no sense, eg. you'd always get "73" at power-on, which isn't exactly random. And you wouldn't want true randomness for devices initial state. I mean, look at all the random bugs we've ran into because we didn't initialize class variables ;D
No.22809 Robbbert Moderator 8 days ago edited on: 8 days ago	Thanks for fixing the 7-segment initial display. The "random" is for a real machine - whatever happens to be in memory location 0000 (I assume - they don't say where it comes from). For MAME it should most likely show FF, but who knows for sure. The code for this driver is so old it predates slots, and could do with a bit of TLC. The computer has (I think) 5 slots for various optional cards. The ones I know of are RAM card, RS232 card, Giant card, and video card. Perhaps the video card uses the CDP1861, but I don't know for sure. Documentation isn't so easy to find these days.
No.22815 Robbbert Moderator 7 days ago edited on: 7 days ago	Making some progress. The display showing FF is because of a bug in mm74c922 - the data-available flag is being set before the new data is available. Every other system that uses this device calls an interrupt, and by the time gets around to reading, the new data is there. But the elf reads the data as soon as DA is asserted, so the bug is evident. Next, the function elf2_state::wait_r needs to have LOAD inverted, otherwise the cpu is stuck in the RESET mode, and so disabling the dma function of the cpu. After that, data can be entered, but the pointer jumps twice, so that's another bug to find.
No.22816 Robbbert Moderator 7 days ago	The pointer bug is an issue inside the cpu, (cosmac.cpp) - the dma_in function gets called once after the dma_in line has been cleared. So the pointer gets incremented while dma is legally active, and then once more after it has been cleared. As usual, I added a patch to my code, but it needs to be fixed properly. It's possible the bug might also occur with dma_out, but the elf doesn't use it. Currently the pointer starts at 0001 instead of 0000, but not sure if that's a bug as yet. Time to see if I can input a program and run it without using the debugger.
No.22818 hap Developer 7 days ago	I've added your mm74c922 and wait_cb fixes. Did this driver work fine in the past? In other words: devices were updated over the years, and this driver was never really tested again until now.
No.22819 Robbbert Moderator 7 days ago edited on: 7 days ago	I've never known it to work, but I had never taken the time to learn how to use it. Certainly it always started with a black screen, so at least the DM9368 problem always existed. Still can't find out how to get the pointer to start at 0000. If I do LOAD off it goes there, but when I switch LOAD on it advances a step when it shouldn't.. Also, for my testing, I added more round LEDs to the layout to show the state of the toggle keys. It would be useful to have them officially there, or maybe words or something. Otherwise the system becomes exceedingly difficult to use since you're essentially working blind. EDIT: Found the 0001 bug, looks like a typo in the CPU. At around line 800 there's a call to run( ), but it should imo be run_state( ) just like everywhere else. I couldn't see where "run" is defined but the name is so generic that it might be someplace else entirely. Doing some regression testing.
No.22821 hap Developer 7 days ago edited on: 7 days ago	Adding the keypad to internal artwork would resolve that (boring work) I don't see run() in cosmac.h, is it in one of the parent classes? Yeah, smells like a typo. File emu/diexec.h: void run() { execute_run(); }
No.22836 Robbbert Moderator 5 days ago	Did some work in my build to fix the remaining issues in this report. The only thing that wasn't reported is that the cassette system doesn't work because the i/o hasn't been hooked up. There's also another bug that needs to go into MAME - when LOAD is off, the IN button must not trigger a dma request. This bug is the cause of the failure of the IN test program mentioned above. There's a diode in the machine that does this function. I added Paste function, and a status display to see what the switches are doing at any time.