Previous Thread
Next Thread
Print Thread
Page 25 of 55 1 2 23 24 25 26 27 54 55
rfka01 #103329 12/29/15 10:35 PM
Joined: Jan 2012
Posts: 1,142
Likes: 2
rfka01 Offline OP
Very Senior Member
OP Offline
Very Senior Member
Joined: Jan 2012
Posts: 1,142
Likes: 2
RBHDREM.TD0, SSIHDINS.TD0 and CLIKCLOK.TD0, DOS310SP.TD0 and DOS310.TD0 (regular IBM PC-DOS 3.1) are DS/DD 360K DOS disks that can be read on an XT or clone, RBADAPKT.TD0 is 80 tracks, SS SD (FM).


NCR DMV- DEC Rainbow- Siemens PCD- ITT 3030-Oly People- Acorn A5000- Olivetti M20
Bavarese #103331 12/29/15 10:54 PM
Joined: Jan 2012
Posts: 869
Likes: 6
C
Senior Member
Online Content
Senior Member
C
Joined: Jan 2012
Posts: 869
Likes: 6
Originally Posted By Bavarese

On another note: the CPU-ID program on RBDS31UT.IMD claims we "incorrectly allow interrupts after a change to SS" (see screenshot).

Old 8088 CPUs (before 1981) had this bug. Is that behaviour wanted / correct?

Assembler source from CPU ID 1.42
https://dl.dropboxusercontent.com/u/37819653/BANNISTER/CPUID.ASM

Hunt for FLG_CERR to find the code to exhibit the bug.

Adding
Code:
m_no_interrupt = 1;

on line 1406 in i86.cpp should make that work properly as according to this it works for every segment register on every 16-bit x86 cpu (except the 286 which already handles it properly).

rfka01 #103406 01/01/16 01:21 PM
Joined: Apr 2012
Posts: 190
B
Senior Member
Offline
Senior Member
B
Joined: Apr 2012
Posts: 190
Thanks so far.

Unfortunately, setting 'm_no_interrupt' does not convince CPUID that everything is correct smile

When the trap flag is set, an interrupt occurs (and the state of 'no_interrupt' does not matter then). I highlighted the relevant sections in I86.CPP and CPUID.ASM.

dec cx is never executed in our present code.

CPU-ID 1.38 (DOS; COM binary for 8088 compatibles)https://dl.dropboxusercontent.com/u/37819653/BANNISTER/CPU.COM




Last edited by Bavarese; 01/01/16 02:04 PM.
rfka01 #103408 01/01/16 03:00 PM
Joined: Jan 2012
Posts: 869
Likes: 6
C
Senior Member
Online Content
Senior Member
C
Joined: Jan 2012
Posts: 869
Likes: 6
Then just swap the m_no_interrupt and m_fire_trap if blocks and check for m_no_interrupt before interrupt(1).

Bavarese #103468 01/03/16 07:37 PM
Joined: Dec 1999
Posts: 1,176
J
Very Senior Member
Offline
Very Senior Member
J
Joined: Dec 1999
Posts: 1,176
Originally Posted By Bavarese
Old 8088 CPUs (before 1981) had this bug. Is that behaviour wanted / correct?


Ideally we should support both types and have each driver specify which variant was shipped with the machine.

rfka01 #103482 01/04/16 11:23 AM
Joined: Apr 2012
Posts: 190
B
Senior Member
Offline
Senior Member
B
Joined: Apr 2012
Posts: 190
You are welcome to improve the CPU cores (or review my DIFFs) grin

I like the idea that NMOS and CMOS CPUs could be defined or set from within the driver. This would make sense for both I86 and Z80.

IMHO, not disabling IRQs after POP SS / MOV SREG is a crystal clear CPU bug that Intel recognized and fixed after 1979 (still NMOS).

Should we really emulate behaviour that makes drivers crash prone? If i am correct, even Ashton Tate warned early IBM-PC users about faulty CPUs.

Last edited by Bavarese; 01/04/16 11:47 AM.
rfka01 #103484 01/04/16 01:50 PM
Joined: Mar 2001
Posts: 16,757
Likes: 29
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,757
Likes: 29
Well, IBM PCs apparently really shipped with the broken parts early on even though the behavior was not desired, so we probably should document it. That said, I'd have it be some sort of clone driver; the parent ibm5150/5160 should use the best possible 8088 emulation.

rfka01 #103485 01/04/16 06:16 PM
Joined: Mar 2006
Posts: 1,055
L
Very Senior Member
Online Content
Very Senior Member
L
Joined: Mar 2006
Posts: 1,055
The Intel SDK-86 shipped with an older 8086 CPU(mine doesn't have a visible datecode (does have a '78-'79 copyright) but the other chips on the board are from 1979).

LN


"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
rfka01 #103486 01/04/16 06:37 PM
Joined: Apr 2012
Posts: 190
B
Senior Member
Offline
Senior Member
B
Joined: Apr 2012
Posts: 190
@R.Belmont: it is documented (somehow) in
src\devices\cpu\i86\i86.txt
Code:
The section reads:
early 8086/8088 revisions bug
-----------------------------
(copyright 1978 on package)
mov sreg, does not disable IRQ until next operation is executed <---

(The last sentence is garbled and broken in my version, so it should be corrected)

Here is my proposition for a patch (please review):
Code:
LINE 145:
            /* Dispatch IRQ */
			if ( m_pending_irq && (m_no_interrupt == 0) )
			{
				if ( m_pending_irq & NMI_IRQ )
				{
					interrupt(I8086_NMI_INT_VECTOR);
					m_pending_irq &= ~NMI_IRQ;
				}
				else if ( m_IF )
				{
					/* the actual vector is retrieved after pushing flags */
					/* and clearing the IF */
					interrupt(-1);
				}
			}

			/* Trap should allow one instruction to be executed. 
			   CPUID.ASM (by Bob Smith, 1985) suggests that in situations where m_no_interrupt is 1,
			   (directly after POP SS / MOV_SREG), single step IRQs don't fire.
			*/
			if (m_fire_trap )
			{
				if ( (m_fire_trap >= 2) && (m_no_interrupt == 0) )
				{
					m_fire_trap = 0; // reset trap flag upon entry 
					interrupt(1);
				}
				else
				{
					m_fire_trap++;
				}
			}

			/* No interrupt allowed between last instruction and this one */
			if ( m_no_interrupt )
			{
				m_no_interrupt--;
			}

		}
		...		
		
~ LINE 696 (already corrected):
		case 0x17: // i_pop_ss
			m_sregs[SS] = POP();
			CLK(POP_SEG);
			m_no_interrupt = 1;
			break;

...
~ LINE 1406:			
		case 0x8e: // i_mov_sregw
			m_modrm = fetch();
			m_src = GetRMWord();
			m_sregs[(m_modrm & 0x18) >> 3] = m_src; // confirmed on hw: modrm bit 5 ignored
			CLKM(MOV_SR,MOV_SM);
			m_no_interrupt = 1; // Disable IRQ after load segment register. Let's not emulate CPU bugs.
			break;


Source and binary for CPUID.COM may be downloaded from the links above for testing purposes.

Last edited by Bavarese; 01/04/16 06:40 PM.
rfka01 #103907 01/28/16 07:15 PM
Joined: Jan 2016
Posts: 70
B
Member
Offline
Member
B
Joined: Jan 2016
Posts: 70
Greetings! I'm new to the forums, so please PM many any etiquette mistakes.

I'm the proud owner of a DEC Rainbow 100B that I bought new in 1983. Over the years, I've added a hard drive, maxed out the memory and written a nice little driver called IMPDRIVE that lets you connect 720k 3.5" floppies.

I have a bunch of technical docs I bought back in the day as well that I plan to scan in once I've taken a survey of everything that is available online. Many of the CP/M related ones seem to be missing, as does the BIOS listing for DOS.

There was a gentleman in the Jemez mountains who disassembled the IO.SYS for the rainbow and added support for TEAC double sided drives. Before he tossed his hardware, he sent me all his disks with source on them. I have them in the basement, but haven't checked on them in years. Hope they are still good.

Reading through this thread, it appears that the latest MESS would actually support rainbow emulation. This thrills me no end since I had half a mind lately to add FreeDOS support for the Rainbow. I last checked out MESS support in maybe 2011 or so, and at the time there was nothing at all for the Rainbow (or what was there wasn't enough to be worth trying). Glad to see things have changed...

I've also been an open source contributor in FreeBSD for two decades.

Reading the thread, it looks like the ROM images that people had may have gone missing? Do you need someone with a Rainbow 100B to read back the ROMs and upload them? Or anything else from the Rainbow docs and/or physical access to the machine? It has been a while since I had it powered on, but will give it a shot tonight if anybody needs anything.

Page 25 of 55 1 2 23 24 25 26 27 54 55

Link Copied to Clipboard
Who's Online Now
3 members (R. Belmont, mfm005, Golden Child), 24 guests, and 0 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,943
Posts117,565
Members4,994
Most Online890
Jan 17th, 2020
Forum Host
These forums are hosted by www.retrogamesformac.com
Forum hosted by www.retrogamesformac.com