PDA

View Full Version : Problems running DX10/DNOS on a TI990/10 simulation



durgadas311
March 9th, 2018, 04:28 PM
I'm having some problems getting DX10 and DNOS to run on a TI990/10 simulation I'm working on. I'm hoping someone here can give some guidance. I am using DS10 and DS50 images from David Pitts web pages.

The simulation seems to be working fairly well, I've been able to run DOCS (also on a DS10 image) and pass the AU4 and MAPTST tests. The DS10PD tests have some issues in the area of write unformatted commands, but I'm thinking that just booting DX10 should not require those to be fully implemented. I see no evidence that DX10 is trying to do anything special in that area. The read unformatted command just always returns 1 sector/record in my simulation. I've also been able to run TX990 on the TI990/4 model with an FD800, and it does not appear to have any problems.

The DX10 3.3.0 image for DS10 seems to fail during boot, showing a fault with code 0030 on the programmer's panel. The most likely reference I found to that code says "read past end of file" but I'm not sure if that fits this situation, or how to tell why it is failing.

The DX10 3.6.0 (and 3.7.0) image for DS50 also hits a fault in boot, but shows the code 002F on the panel. I haven't found a reference to that code so have nothing to go on.

The DNOS image for DS50 seems to boot without fault, and shows idle and C2D6 on the programmer's panel. The 911 VDT shows the signon message, but I can't get the command interpreter to start. I can trace the keyboard interrupts and see that the command sequences is being recognized, but nothing happens. Actually, it seems that the code is only looking for the sequence GOLD + CR, while the documentation states that GOLD + '!' is the correct sequence. Perhaps that indicates what state the OS is in, such that it has not reached the point where it is looking for the sequence GOLD + '!'. Neither sequence has any visible affect, but the GOLD + CR is being recognized by the interrupt routine. I'm wondering if some problem has prevented the DNOS boot from completely, so the command interpreter is not yet available.

Any pointers would be appreciated. Even some recommendations of additional tests to run.
Thanks,
Doug

For those curious, http://sims.durgadas.com/ti990/ti990.html

Al Kossow
March 9th, 2018, 04:40 PM
I'm having some problems getting DX10 and DNOS to run on a TI990/10 simulation I'm working on.

Can you run it in lockstep with Dave's simulator or MAME?

durgadas311
March 9th, 2018, 05:48 PM
Can you run it in lockstep with Dave's simulator or MAME?

I'm not sure how to run in lock-step with Dave's simulator. Are there hooks to do that?

I just noticed that Dave's simulator actually has a special boot function for the disk, so it appears to not be using the boot code in the ROM. I'll study that some more to see if anything pops to mind. I'm wondering what's wrong with the ROM boot routine.

durgadas311
March 10th, 2018, 03:58 AM
I just noticed that Dave's simulator actually has a special boot function for the disk, so it appears to not be using the boot code in the ROM. I'll study that some more to see if anything pops to mind. I'm wondering what's wrong with the ROM boot routine.

Looks like Dave's dskboot() function is just a convenience, to be able to boot without having a ROM installed or requiring user intervention.

durgadas311
March 10th, 2018, 09:35 AM
I got a core dump from both systems, but am not sure what to make of the differences. I guess I'll continue to analyze the diffs to see what pops out.

durgadas311
March 10th, 2018, 01:14 PM
One difference I see is the task state for "TBID". In my case, the task state is >13 "Waiting on system overlay loader services" and the sim990 instance is state >24 "Task suspended for queue input" (I suspect waiting for keyboard input). That seems pretty obvious, but still not sure how to track down what event was missed. Presumably some disk I/O, so I'll look closer there.

The system that faults does seem to timeout before displaying fault 002F, so perhaps it is just some misplaced disk interrupt. Maybe my simulation needs to respond a little slower to commands. It already uses a background thread to perform the disk commands asynchronously from the CPU/program, but perhaps it is still too fast. Or else there is some race whereby the interrupt gets lost.

durgadas311
March 11th, 2018, 05:06 AM
All issued disk commands receive interrupts, but it is hard to tell if the entire overlay was loaded. I can see file table information being read, but don't know how to interpret that. Perhaps I can trace disk I/O and interrupts on sim990 and compare.

durgadas311
March 11th, 2018, 11:23 AM
I cleaned up the timing of the disk simulation, making it more authentic, but still no joy. My simulator just stops after reading a couple blocks and times out, while sim990 continues reading more blocks. I suspect some subtle corner-case bug in the CPU simulation, but tracking that down will be difficult as long as I don't know what is supposed to be happening.

Does anyone know where to find more information about the disk/file layout?

durgadas311
March 22nd, 2018, 05:12 PM
I was able to track down the problem. After finding several bugs, none of which fixed the problem, I discovered a bug generating the carry bit when subtracting zero.

Al Kossow
March 22nd, 2018, 05:40 PM
I was able to track down the problem.

Good job!