|
Joined: Jan 2012
Posts: 1,180 Likes: 17
Very Senior Member
|
Very Senior Member
Joined: Jan 2012
Posts: 1,180 Likes: 17 |
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
|
|
|
|
Joined: Jan 2012
Posts: 891 Likes: 17
Senior Member
|
Senior Member
Joined: Jan 2012
Posts: 891 Likes: 17 |
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 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).
|
|
|
|
Joined: Apr 2012
Posts: 193
Senior Member
|
Senior Member
Joined: Apr 2012
Posts: 193 |
Thanks so far. Unfortunately, setting 'm_no_interrupt' does not convince CPUID that everything is correct 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![[Linked Image from dl.dropboxusercontent.com]](https://dl.dropboxusercontent.com/u/37819653/BANNISTER/Single_Step_IRQ_sized.jpg)
Last edited by Bavarese; 01/01/16 02:04 PM.
|
|
|
|
Joined: Jan 2012
Posts: 891 Likes: 17
Senior Member
|
Senior Member
Joined: Jan 2012
Posts: 891 Likes: 17 |
Then just swap the m_no_interrupt and m_fire_trap if blocks and check for m_no_interrupt before interrupt(1).
|
|
|
|
Joined: Dec 1999
Posts: 1,180 Likes: 2
Very Senior Member
|
Very Senior Member
Joined: Dec 1999
Posts: 1,180 Likes: 2 |
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.
|
|
|
|
Joined: Apr 2012
Posts: 193
Senior Member
|
Senior Member
Joined: Apr 2012
Posts: 193 |
You are welcome to improve the CPU cores (or review my DIFFs) 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.
|
|
|
|
Joined: Mar 2001
Posts: 17,239 Likes: 263
Very Senior Member
|
Very Senior Member
Joined: Mar 2001
Posts: 17,239 Likes: 263 |
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.
|
|
|
|
Joined: Mar 2006
Posts: 1,080 Likes: 7
Very Senior Member
|
Very Senior Member
Joined: Mar 2006
Posts: 1,080 Likes: 7 |
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!"
|
|
|
|
Joined: Apr 2012
Posts: 193
Senior Member
|
Senior Member
Joined: Apr 2012
Posts: 193 |
@R.Belmont: it is documented (somehow) in src\devices\cpu\i86\i86.txt
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):
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.
|
|
|
|
Joined: Jan 2016
Posts: 76 Likes: 5
Member
|
Member
Joined: Jan 2016
Posts: 76 Likes: 5 |
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.
|
|
|
0 members (),
53
guests, and
6
robots. |
Key:
Admin,
Global Mod,
Mod
|
|
Forums9
Topics9,331
Posts122,197
Members5,077
|
Most Online1,283 Dec 21st, 2022
|
|
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!
|
|
|
|