Home Page

Requirements?

Posted By: rfka01

Requirements? - 01/01/12 10:45 PM

What's the minimum amount of information or files needed to consider inclusion into MESS for the following systems:

NCR DMV (Z80, 8086 and 68008)
Siemens PC-D (80186)
DEC Rainbow 100

I have BIOS files for the first two systems (haven't opened the Rainbow yet) and disks to test ... also quite some amount of technical documentation for each of the machines.

Thanks, Robert
Posted By: R. Belmont

Re: Requirements? - 01/01/12 10:51 PM

Dumps for all of the ROMs (the system BIOS plus any video character-generator ROMs) are basically bare minimum. Disk images and technical documentation of course are great bonuses smile
Posted By: judge

Re: Requirements? - 01/02/12 01:25 PM

And preferably PROMs too
Posted By: Haze

Re: Requirements? - 01/02/12 01:36 PM

but if the system works, make a video of it booting up, and possibly running something *before* you start taking it apart and de-soldering bits.. just in case ;-)

Obviously not *required* but it's general good advice, as people have been known to break things, leaving us with no idea how it's actually meant to look.

(This obviously changes for stuff like NOS of HDD based systems where ideally you'd want the drives dumped in a completly untouched never booted state, keep floppies write protected and such too)
Posted By: rfka01

Re: Requirements? - 01/02/12 10:17 PM

Hello everybody ... my Eprommer just packed in ... *aaaaargh* ... so until I get that fixed, here's what I've got:

NCR DMV:
Floppy images for NCR DMV in Teledisk/CopyQM format
NCR DMV Rom Images
A Link to some System information (I'll scan more)
Manuals et al.

Siemens PC-D
Some PC-D Floppy Images to test
PC-D ROM Images

Videos of the Systems shouldn't be a problem ... what's bothering me more is finding a way to read the proms, mabye they're pin compatible with some supported eproms or I can read them through software.

Robert
Posted By: Lord Nightmare

Re: Requirements? - 01/02/12 10:34 PM

for reading proms, before i got a programmer which handled them, i used a piece of solderless breadboard (yknow, with the holes with little springy wipers inside) and a dip24-ended cable which i'd plug one side into programmer and the other into the breadboard
then wire up, with wires, the expected 2732 or mc68764 pinout of the programmer to the inputs and outputs of the prom; this works very well for proms up to 64kbit in size.

Also, sometimes the new programmer refuses to read a chip (phantom overcurrent, pins that are unconnected internally, and sometimes just plain luck), and when that happens i go back to the old system. Currently I have the breadboard wired up with a crystal and a 9v battery (to supply -5v in a hackish way) in order to dump intel 8021/8022 chips.

LN
Posted By: Micko

Re: Requirements? - 01/04/12 10:16 AM

Hi Robert,

I have added these two machines as skeletons for now. Thing is that in DMV rom images you placed two same (from Z80) so 68k one is missing. Can you please upload new one ?

Also, we are very interested in DEC Rainbow 100 smile

Thanks,
Micko
Posted By: rfka01

Re: Requirements? - 01/04/12 11:15 AM

Excellent, thanks ... I'll see what I can do about the Rainbow.

I'm just digging out information at the moment: The thing about the two DMV hex images was, that one machine would accept my 68k module, the other not. This is why I dumped their respective ROMS (so they're both main ROMs from the Z80 mainboard)... I now found out that it's not the ROM after all, but the type of internal 8086 adapter used. The one that accepts the third (68k) coprocessor has interrupts enabled ... I'll try to dump its proms' content tonight.

It would be very helpful if you could tell me what specific information or code is needed next.

Thanks for all the efforts, this is a dream coming true.

Robert
Posted By: rfka01

Re: Requirements? - 01/04/12 11:37 AM

Seems this saves me scanning the DEC Rainbow 100 technical manual ...

DEC Rainbow 100 Technical Manual
Misc. Information

It would be great to emulate the Rainbow 100B with maxed out memory, a choice of b/w and colour monitor and harddisk.

Robert
Posted By: rfka01

Re: Requirements? - 01/04/12 11:45 AM

The disk image found here

Rainbow 100 disk image

originally came from me, it could be used for testing.

As an aside,
the keyboards of the systems mentioned in this thread are very distinct from standard AT type keyboards. What is needed to provide keyboard support?

Robert
Posted By: Micko

Re: Requirements? - 01/04/12 11:58 AM

Hi,

thanks for new links. about keyboards, thing is that most of them have MCU (micro controller unit) that mostly have protected rom content, so in most of cases we simulate them, and this is case in "detached" keyboards (since they use serial communication over a cable), "integrated" keyboards mostly have some kind of simple matrix and supported electronics for direct read.

As I see in technical documentation there is 24K rom in form of 3 * 8K and also 4K rom for char gen, video chip is same as in VT100 so that is good since we made it already.

So we need those 4 chips dumped in this case.
Posted By: rfka01

Re: Requirements? - 01/04/12 12:52 PM

I just found this

Model B Rom Images

with the Rainbow 100 Model B ROM images. Wiki mentions that instead of three, it only uses two chips for the ROM, this is consistent with my mainboard.
The third EPROM must then be the character generator which I'll try to dump tonight ... I'll bring out my old DELA Eprommer II ;-)

Robert
Posted By: Micko

Re: Requirements? - 01/04/12 12:56 PM

ok so it's probably different mainboard then, since there was 3 * 8K and here is 2*16K that makes it 32K instead of 24K.

Nice find anyway.

Micko
Posted By: Micko

Re: Requirements? - 01/04/12 01:09 PM

Also it would be nice if you could give DEC part numbers for these two roms and one to be dumped. (those should be written on rom itself)
Posted By: Chris44

Re: Requirements? - 01/04/12 11:19 PM

I have a number of IBM incompatibles in my collection. I'll attempt to list them -

NEC APC

NEC APC III w/SLE board

Mindset

Tandy 2000

Epson QX-10 w/Titan (arguable a *real* compatible though I guess, w/addition of Titan board. QX-16 was more or less the same AFAIK)

Xerox 16/8

Canon AS-100

IBM Displaywriter (?) - not a DOS puter

DEC Rainbow

Canon VP-3000 (a dedicated word processor, doesn't run any form of DOS AFAIK. If anyone has disks or images for it though, please let me know).

Televideo Personal Mini PM/16T (I think that's the model I have, not a DOS puter per se)

Northstar Dimension (also not a DOS puter, at least not natively)

AT & T 6300 (largely a compatible I guess)

Research Machines NIMBUS PC-1? motherboard only

that's all I can think if right now. Getting images made of these dinos will take time, seeing I have a hernia or something, and can't lift much.

Do you mean to tell me creating a hex dump w/BASIC isn't a useful image (of sorts)?
Posted By: R. Belmont

Re: Requirements? - 01/04/12 11:27 PM

That's a nice collection!

For machines of that age, a hex dump in BASIC (or DEBUG.COM) is fine if you don't have any access to an EPROM reader.
Posted By: Chris44

Re: Requirements? - 01/04/12 11:42 PM

thank you. I broke my back getting some of it.

how about we dedicate a thread or part of this one to naming E-V-E-R-Y pseudo compatible out there? I name a bunch on the front page of the Tandy 2000 yahoo group, and that reminds me of a few other:

Sanyo MBC-555 (nominally a real compatible, in the same way a PCjr was anyway (i.e limited by memory capacity and such).

Victor 9000/Vicky (portable version)

Texas Instruments Professional/Portable Professional

there are quite a few others (which I don't own). Seiko, Mitusbishi, 2 rather phenomenally gorgeous units generally only found in Japan.
Posted By: Lord Nightmare

Re: Requirements? - 01/05/12 12:18 AM

Ooh you have a vicky? can you dump the bios roms from that? we have the f3f7 universal roms and one older rom in mess but there's supposedly at least half a dozen versions we're missing including the slightly older f3f6 universal version, and several from machines with 2 floppy drives and no SASI hdd.
Edit: wait, are you ChrisM from the classiccmp list? I remember talking to you back in 2007 re:vicky and v9k machines, if so.
google for 'f3f7 universal victor' without 's and you'll find the thread.


LN
Posted By: Chris44

Re: Requirements? - 01/05/12 12:27 AM

I am

Is this Jonathan G.? I was corresponding w/he and another guy in the Seattle area. Sorry I never got you rom dumps, and the Vicky - I'm not sure which storage unit it's in (in any event, buried deep). I will get to this stuff (I might need you to send me another boot disk though wink. Actually I'll just read over your method of creating one from an image. I saved the correspondence. You're a maniac for that nefarious piece of wickedness by the way wink
Posted By: Lord Nightmare

Re: Requirements? - 01/05/12 12:45 AM

Yes, this is he!
Edit: Crafting a victor bootdisk from an image is non-trivial: it can be done on a catweasel or similar hardware, but is best done from another working victor machine, due to the weird drive.
Contrary to what was said in that thread in 2007, my victor machine does not have any special 1.44mb MFM drive; its the normal 1.2M custom-variable-speed-chuck-peddle-GCR one that all victors/sirius1 machines came with.

LN
Posted By: Micko

Re: Requirements? - 01/05/12 09:47 AM

Chris44:

This is very nice collection. Some of those can be dumped using debug, but since these are not full ibm compatibles, not sure if they expose all roms visible, so at least making images of inside of machines would be nice to confirm roms sizes and additional hardware. Getting real eprom reader to dump them would be cool.

Micko
Posted By: rfka01

Re: Requirements? - 01/05/12 10:15 AM

Here are some more files:

I dumped the ROMs of the three Rainbow 100's I have - all are model B's - so they could well be identical, but I haven't checked. There's a text file inside the archive with descriptions of the machines and their add-on cards.

DEC Rainbow 100 ROM images

The video card that provides graphics (rather than text) output is present in two of my three machines, it's using the 7220 controller. I can't read the two PAL chips on it atm, maybe someone else can jump in here.

If you want some (very bad) video clips of the "maxed out" Rainbow in action, here they are:

From switch on to MS-DOS from the Winchester

DOS and WordPerfect for the Rainbow

Windows 1.03 and Write

I have to start Windows by entering the application program I want to see - plain "win" gives a blank "MS-DOS" window ... it's waiting for something, either a disk to come online or a mouse.

Robert
Posted By: Micko

Re: Requirements? - 01/05/12 10:37 AM

Hi,

_1 looks fine, they are all same as on site you gave link for initial dumps. Also video rom looks fine (except RB100_B3_3.HEX that is blank).

The _2 roms look strange like they have stucked bit's.

RB100_B3_2.BIN FIXED BITS (xxxx1xx1)

Also RB100_HD_2.BIN RB100_B_2.BIN are different then original dump, but variable stucked bits.

Will hook up video rom to check how it looks.

Posted By: Micko

Re: Requirements? - 01/05/12 10:44 AM

Also on roms there are markings something like 23-094e2 (as on VT100) that is DEC part number can you write those from chips ?
Posted By: rfka01

Re: Requirements? - 01/05/12 11:00 AM

Sorry, apart from the part numbers (2732 or 27128) the ROMs in all three machines only have white blank labels to shut out the light.

The stuck bits might well be due to the eprommer I'm using (on a C128), as my regular one has packed in. frown

Robert
Posted By: rfka01

Siemens PC-D - 01/06/12 12:29 AM

OK ... I've ordered an eprommer from Hongkong ... should be a while to arrive. In the meantime I've re-tried with my old one, and I've taken lots of pictures. I'll break this up machine by machine.

The PC-D has the mainboard, a graphics board and a (I guess) SASI=>MFM harddisk controller.
The keyboard is non-standard, warm start is rather PC-style with Ctrl-Alt-Lschen (which is of course delete)

Pictures Siemens PC-D
Posted By: rfka01

Re: Siemens PC-D - 01/06/12 12:34 AM

The NCR DMV has lots of little options modules that plug into the mainboard at the back of the machine. Together with the internal slot, this is one heck of a machine.

I've taken pictures of the mainboard and the modules I have, for most of them I also have the technical documentation:

Pictures NCR DMV

They keyboard is non-standard again, warm start is via Ctrl-F20.

The internal 8086 (or rather V20) module is special, as it allows the 68k module to be added externally. This allows a wide range of OS: CP/M-80, CP/M-86, DOS, CP/M-68k and USCD-Pascal are the ones I know of.

I've dumped the ROM of the 8086 module with my old eprommer:

NCR DMV 8086 option ROM

The hard disk is in an external enclosure that is connected via an option module that in turn connects to a SASI=>MFM controller, as you can see in the pictures.
Posted By: rfka01

Re: Siemens PC-D - 01/06/12 12:39 AM

The DEC Rainbow 100 is packed with option boards. I've taken pictures of the mainboard, the floppy controller, the HD controller (MFM), the graphics board and the memory expansion.

The keyboard is (again) non-standard, F3 enters a monitor, Ctrl-F3 is the warm start.

Pictures DEC Rainbow 100

The small 4K ROM actually has a DEC marking on it ... 23U37E300 ... missed it the first time, sorry.
I've re-dumped the ROMs that Micko mentioned in one of his last posts, but will re-do them again soon.

More ROM dumps of the DEC Rainbow
Posted By: R. Belmont

Re: Siemens PC-D - 01/06/12 01:27 AM

Those are nice pictures and good info. The DMV sounds like quite an interesting machine!
Posted By: Micko

Re: Siemens PC-D - 01/06/12 12:59 PM

Thanks for additional images. I am out this weekend so can take a look at all next week.
Posted By: rfka01

Re: Siemens PC-D - 01/06/12 10:56 PM

I found some technical documents for chips used in the systems:

NEC 7220D Graphics controller (Rainbow + DMV)

NEC D8741AD Peripheral Interface Controller (PC-D Graphics, DMV Mouse), has 1KB ROM area

SCN2674B Graphics Controller (PC-D Graphics)

Controller tech docs

Robert
Posted By: Stiletto

Re: Siemens PC-D - 01/07/12 12:14 AM

Originally Posted By rfka01
I found some technical documents for chips used in the systems:

NEC 7220D Graphics controller (Rainbow + DMV)

NEC D8741AD Peripheral Interface Controller (PC-D Graphics, DMV Mouse), has 1KB ROM area

SCN2674B Graphics Controller (PC-D Graphics)

Controller tech docs

Robert


I'll double-check, but I think we already host these either publicly or privately. Thanks for what you are doing though! laugh

[EDIT] I take it back, only the SCN2674 is being hosted at all. Thanks for the heads' up!
Posted By: rfka01

Re: Siemens PC-D - 01/07/12 09:06 AM

You're welcome. I've looked at the MESS driver code ... there's no way I can contribute directly ;-) so I'll resign myself to supporting as best as I can ;-)

Robert
Posted By: rfka01

Re: Siemens PC-D - 01/09/12 07:19 PM

Hmmm ... I'm missing something here:

I compiled MESS, put the BIOS and chargen images into rainbow.zip, put it in \roms, put the disk images mentioned in rainbow.xml into roms\rainbow, but MESS won't let me start emulation, it comes up with "The selected game is missing one or more ROM or CHD images".

This procedure was the result of some searching, so please be gentle with a noob ;-)

Robert
Posted By: Micko

Re: Siemens PC-D - 01/09/12 07:38 PM

you need roms from link you sent + your char rom dump (note that you have two bytes at start that are not part of dump so you need to remove those two)

Posted By: etabeta78

Re: Siemens PC-D - 01/09/12 08:01 PM

also, which command line options did you exactly use?
Posted By: Kaylee

Re: Siemens PC-D - 01/09/12 08:33 PM

and a few notes, from running it:

1: there is no disk drive defined
2: doesn't really boot *

*

Get's to there
Posted By: rfka01

Re: Siemens PC-D - 01/09/12 08:44 PM

Thanks, Micko.

I've removed the two bytes, the Hashes and CRCs match the ones in rainbow.c, but no joy so far.

@etabeta: I just started mess64.exe and tried to launch the Rainbow driver from the list. I'll try launching it from the command line.

Robert
Posted By: rfka01

Re: Requirements? - 01/09/12 09:42 PM

I had the two main ROMs mixed up ... sorry!

The error displayed is (of course frown ) not in the Owner's manual. A "real" Rainbow has a strip of LEDs for diagnostics ... maybe that could be emulated as well?

The disk drives are DEC RX50's,

e.g. DEC RX50

I found a Rainbow 100 diagnostic disk in a stack that I had not imaged until now ... maybe that helps once a disk drive is added.

DEC Rainbow 100 Diagnostic Disk

Robert
Posted By: rfka01

Requirements? Rainbow 100, NCR DMV, Siemens PC-D - 01/10/12 06:00 PM

In the NCR DMV driver there's a place reserved for the keyboard ROM, I've just checked, it's another D8741AD ... how can the ROM of these chips be read?
The system technical manual has the listings for Version 1 (which means US English, UK English, Danish, German, Swedish/Finnish, Norwegian, Spanish, Italian) and Version 2 (Swiss-German, Swiss-French, French, Canadian/Australian, Canadian (Bilingual), South African, Portuguese, Yugoslavian (yes, the 80's))
So in theory they could be OCR'd and recompiled.

As for the Siemens PC-D, when the skeleton was added, it was added to pc.c ... but somehow I can't find it.

Robert
Posted By: Lord Nightmare

Re: Requirements? Rainbow 100, NCR DMV, Siemens PC-D - 01/10/12 06:01 PM

D8741 can be read by almost any programmer which can program intel or nec 8741 chips. If you sent the chip here I could read it in 5 minutes, assuming it isn't protected.

LN
Posted By: rfka01

Re: Requirements? Rainbow 100, NCR DMV, Siemens PC-D - 01/10/12 07:32 PM

What programmer are you using?

Robert
Posted By: Lord Nightmare

Re: Requirements? Rainbow 100, NCR DMV, Siemens PC-D - 01/11/12 03:53 AM

bpmicro bp-1200

LN
Posted By: Chris44

Re: Requirements? Rainbow 100, NCR DMV, Siemens PC-D - 01/13/12 01:16 AM

I'm not on the net a lot lately. Certainly not consistently. So if my replies seem disjointed, it's...just...the...way...I..am

I'd be willing to donate a Rainbow (no k/b) or Victor 9000 (probably non-functional) to "the cause" for shipping. Or if the interested parties just want parts (say mobo or whatever) to lessen the brunt of shipping, I could do that also. Looks like rfk01 has all the R* hardwarez he needs though.

Jonathan, I'll get you those roms I swear it LOL.

Posted By: Chris44

Re: Requirements? - 01/13/12 01:20 AM

Micko, my JDR Microdevices eprommer was broken when I bought it (and payed 50$ too). I guess I should work on that. I'm not even sure where it is. Oi.
I sent you a private message btw.
Posted By: Chris44

Re: Requirements? - 01/13/12 01:27 AM

rkf01,
Just what is an NCR DMV??? I know what a Decision Mate is, as well as a PC4/PC4i (have 3 in less then mint condition, all green), but never knew of a DMV. I did see what likely was a Data Mate or something (met this Mormon lady who worked for NCR, and was the only person on planet earth who seemed to know what I was talking about. I saw the thing in a thrift store, but declined to grab it, wasn't a collector per se yet).
I know you're busy. When you get a chance, can you provide a picture? I have a sneaking feeling I know basically what it looks like already (sort of like a Lisa, right?).
I'll probably wind up giving away 2 of the NCR PC4s before long. If anyone's interested. I passed up a color model once, practically brand new. I'm still kicking myself.
Posted By: Chris44

Re: Requirements? - 01/13/12 01:30 AM

ok never mind. I'd removed the post if I could. Now I look foolish. Decision Mate V. Oi.
Posted By: rfka01

Re: Requirements? - 01/15/12 11:21 AM

Hi Folks,
this document describes the conversion of a Rainbow 100A to a 100B ... so in reverse this might help to understand the differences between the pictures and files for the machine I posted and the one described in the Technical Manual.

Conversion RB100A to B http://dl.dropbox.com/u/55419307/RBCONVRT.ZIP

Robert
Posted By: rfka01

Re: Requirements? - 01/16/12 02:26 AM

This document shows how the (colour) graphics option, that is present on my machine, works on the Rainbow.

Rainbow Graphics Option

Robert
Posted By: R. Belmont

Re: Requirements? - 01/16/12 03:27 AM

Nice work coming up with all that documentation! smile
Posted By: rfka01

Re: Requirements? - 01/16/12 08:03 PM

... and here's some more. This is a scan of the "PC 100 System Specification" ... and is very informative about the way the various parts of the system talk to each other (e.g. shared RAM, what CPU gets to control which pieces of hardware).

PC100 System Specifications

Robert
Posted By: rainbow_will

Re: Requirements? - 01/17/12 09:22 PM

Greetings fellow computer preservationists!
'rfka01' got me interested in this and I am attempting to come up to speed on the rainbow project. I've done some minor simulation work of PDP11 systems in the past and am amazed at the scope of MESS. It will be a while before I can make any useful contributions, but I will watch with interest.

I haphazardly maintain
http://www.willsworks.net/pdp11/decmicro.htm.
So I am a Rainbow fan. I would also like to submit DEC's VT-180 (aka Robin) computer for consideration. It is described on the page above with links to the Technical Reference Manual and some disk images which are available at
http://bitsavers.org/pdf/dec/terminal/vt180/
This was a Z80 based CPM 2.2 system with 64Kb of memory which was housed in a VT-100 terminal. I think its similar to the Z80 half (CPM80) of a Rainbow.

I've also located some ROM images at
http://www.dunnington.u-net.com/public/DECROMs/
per the file, ROMlist, I believe 23-017E3 and 23-021E3 to be the boot ROMs. The character display was handled by the VT-100 board, and I suspect that 23-018E2 will work as a character generator, but a quick inspection shows it also includes some of the setup strings.

I own a couple of both these systems, although only the rainbow is physically accessible at the moment.

Will
Posted By: rfka01

Re: Requirements? - 01/19/12 07:31 PM

This is the keyboard ROM for the Siemens PC-D complete with two pictures of the pcb inside.

Siemens PC-D keyboard ROM and pix

The DMV has D8741AD inside the keyboard which I can't read yet, I haven't found a way to get inside the Rainbow keyboard without destroying it, maybe Will can shed a light onto what to expect there.

Robert
Posted By: rainbow_will

Re: Requirements? - 02/26/12 09:52 PM

I'm not as prolific, nor dedicated as my internet friend rfka01!
However I did just log in and see he pointed his finger at me last month regarding Rainbow Keyboards. I have never opened one up, but do have some spares I will be near next month if that is required. However I think emulation would be the way to go and the link below gives a lot of information:
http://www.netbsd.org/docs/Hardware/Machines/DEC/lk201.html

In overview the LK-201 keyboard used RS-232 at 4800 baud. I
believe his interface was used with most of the Decmates, the Pro-350, and some of the Microvax which is why its on the netbsd site. On the Rainbow, Decmate, and Pro-350 the 4 pin LK-201 connector plugged into the back of the VR-201 monitor and was then routed to the DB-15 monitor connection on the back of the Rainbow. The Update site below has a lot of good old rainbow info, the file indicated below gives pinout info for this DB-15.
ftp://ftp.update.uu.se/pub/rainbow/doc/VR241.txt

So in terms of hardware, I believe the keyboard acts like a serial line unit on the appropriate pins off this DB-15. On the Microvax the keyboard plugged directly into the CPU unit. Its off topic, but for the record I have a microvax that I occasionally play with using my PC as a serial terminal for the keyboard.

I have always used the MSDOS bios interface to interact with the Rainbow keyboard when writing code for it, and am not sure where that fits in. Presumably the keyboard Uart interacts with the bios routines but I have no knowledge of this level. If useful I can document the key codes produced by the bios routines on my rainbows, let me know.
But I fear we need to obtain listings or disassemble the bios a little to see how it interacts with the keyboard to do an emulation.

I'm interested in this entire project, but primarily in the Graphics option card with which I have been experimenting. I have a copy of a manual similar to the one rfka01 made available a few weeks ago in postscript format, but had never seen the *.DOC version (although they seem identical). For those interested in documentation, if you haven't seen it there is an on-line version of the NEC-7220 manual available, although most of this information is duplicated in the link rfka01 posted, the additional DEC ports and differences regarding the Rainbow are of significant interest, as are the graphics pixels apparently available in the bitmap which can't be displayed!
http://electrickery.xs4all.nl/comp/qx10/doc/nec7220.pdf

luck!
Posted By: Lord Nightmare

Re: Requirements? - 02/26/12 10:42 PM

oh dear f***ing god. an LK201 keyboard is the most evil unmaintainable piece of equipment DEC ever put out; It was followed by the mostly-backwards-compatible and more tolerable LK401 keyboard (which doesn't fail QUITE as often and is not QUITE as irrepairable from what I've been told). It has an unusual propensity for spontaneous failure, and the entire inside is held together with melted plastic spikes, making it impossible to disassemble and repair. The membrane (it is one of the earliest 'open membrane' (read: cheap) keyboards made is held permanently bent (unlike the membrane in an ibm/lexmark model M keyboard, which despite being clicky does use a membrane, but one held perfectly flat), causing it to wear out unusually quickly from constant stress on the plastic; also holding keys down for an extended period of time by something sitting on top of the keyboard will cause the membrane layers to weld themselves together causing stuck keys, which because of the plastic spikes is impossible to fix. Not to mention that the keyboard mcu will fail its power on self test and refuse to work if any keys are stuck down, rendering the keyboard an obscene giant paperweight.
to make matters even MORE fun: the way the membrane is attached to the pcb with the MCU on it is using these metal one-piece clamps, which make it almost completely impossible to remove the membrane without damaging it further (you have to sort of shove part of a credit card in between the membrane and the contact spikes, them yank the membrane out hopefully not scraping off the contact layer on the credit card!)

There are two versions of the LK201: one has red LEDs and has an Intel MCS-48 series MCU, and the other has green LEDs and has a mc6800-series (or maybe Hitachi 6300-series) MCU; the clock crystals used on both versions are different.

I have a damaged/irrepairable LK201 of some variety here, as well as two working ones, one with red LEDs, and one with green LEDs.

No offense is intended to rainbow_will by this post, I just can't stand the rampant reliability issues with lk201 keyboards; fortunately there seem to be quite a lot of them out there so getting spares is not a major deal yet.

The lk201/401 is used by, at least:
VT220
VT240
VT320
VT340
Rainbow
VT420
VT440?
The vt520 does not use it; it uses a plain ps/2 keyboard.
Although a special VT520 PS/2 keyboard with extra DEC keys is what you're supposed to use with it, it will work fine with any PS/2 keyboard.

LN
Posted By: rainbow_will

Re: Requirements? - 02/27/12 02:26 AM

no offense take Lord Nightmare, but interesting comments. I really don't think I've had one fail, but given your input I don't think I'm eager to take one apart either!

I found (long ago) one other source which is a zipped collection:
ftp://ftp.update.uu.se/pub/rainbow/doc/rbtecdoc.zip
I recommend miscin.doc which has some discussion of where
the keyboard buffer and counter are stored in memory.
And rbgibm.doc which talks about differences between ibm
and rainbow bios.

I still have not attempted to look at the code in detail, but how do you know where to locate the ROM images you guys obtain?

Regards, Will
Posted By: rfka01

Re: Requirements? - 02/27/12 08:39 AM

Reading all this with interest ... thanks for all the information rainbow_will and LN ... let me know when to chime in and trawl for specific information.

Robert
Posted By: rainbow_will

Re: Requirements? - 02/27/12 04:33 PM

Sorry, I would like to retract yesterdays question about where to place the ROM images in memory, the Rainbow 100 Technical Manual, pc100tm1.pdf, has more info on this than I can
absorb! It also contains a good description of how the keyboard 8251A PUSART works, see section 4.4.14 starting on pp 4-75
Posted By: rfka01

Re: Requirements? - 02/29/12 09:04 PM

Some more technical documentation about the DEC Rainbow 100

Rainbow 100 Technical Docs

There's some interesting stuff about the interplay of the processors, also a good description of the video part.

Robert
Posted By: rfka01

Re: Requirements? - 03/01/12 09:22 PM

I've put system disks of the PCs in question here through the Anadisk floppy format analyser, these are screenshots from the program.

NCR DMV:
DOS disk:




CP/M-80:


CP/M-86:


CP/M-68k:
http://dl.dropbox.com/u/55419307/DMV%20CPM-68k.JPG
Posted By: rfka01

Re: Requirements? - 03/01/12 09:23 PM

Siemens PC-D:

Dos Disk:




Posted By: rfka01

Re: Requirements? - 03/01/12 09:25 PM

DEC Rainbow:

DOS disk:


CP/M-86/80 disk:



Robert
Posted By: rfka01

Re: Requirements? - 03/19/12 11:25 AM

I have compiled a list of ICs to be read from these three and the Oly People system ... my own eprommer doesn't seem capable of doing this, and I'm not that savvy to cobble together my own reading tools.
I wouldn't mind posting the boards to some location in Europe (a heavy package to the USA seems prohibitively expensive), provided I get them back whistle ... it would be great if somebody who has the means of reading these parts could contact me.

I hope I included all the parts in this list, sometimes it's hard to find information on the function of the ICs ... if somebody finds more parts needed on the pictures I posted, I'll include them in this list.

ICs to be read

Robert
Posted By: Darkstar

Re: Requirements? - 03/19/12 12:05 PM

Let's see...
the 8741A/AD is an I/O chip and shouldn't need dumping. The NEC 7220 is a display controller and also shouldn't contain a ROM, so no dumping there either.

The PALs do need dumping, but they require special hardware for that. They could get implemented in software though, so they are not necessarily required for "working" emulation

-Darkstar
Posted By: Lord Nightmare

Re: Requirements? - 03/19/12 01:34 PM

Originally Posted By Darkstar
Let's see...
the 8741A/AD is an I/O chip and shouldn't need dumping.


Incorrect. The i8741 is most definitely an MCU with rom, a member of the MCS-41 family; it is often used as a keyboard controller on the motherboard of 286 or greater IBM PCs, but appears in other places as well.

LN
Posted By: rfka01

Re: Requirements? - 03/19/12 01:44 PM

Hi,

that's a bit of relief ... I think you're correct about the 7220, seems I got mixed up in the thousands of non-results you get when you google classic ICs. The 8741 microcontroller has a 1k EProm though, so I'll probably have to get them dumped.

Robert
Posted By: rfka01

Re: Requirements? - 03/19/12 01:46 PM

LN was quicker ... thanks for the clarification!
Posted By: Darkstar

Re: Requirements? - 03/19/12 03:44 PM

Originally Posted By Lord Nightmare
Incorrect. The i8741 is most definitely an MCU with rom...

Bah, you're right of course. I wasn't fully awake when I posted that, and trusted google without thinking smile

thanks for the clarification

-Darkstar
Posted By: Bavarese

Re: Requirements? - 05/06/12 01:18 AM

Hi,

thanks for all the info so far

A hint for all noobs trying to get this working: the current state of emulation in MESS indicates the "DEC Rainbow 100" emu is "non working" and "without sound".

All you will see is a black screen with diagnostic error 18 (and probably error 16). This indicates a problem with the Z80 subsystem (CRC error).

I refer to the compiled versions of 'messui145u7b' and 'mess_winui_32bit_r14889' available on the net.

Guess the board logic is incomplete / not implemented yet...






Hope we will se some progress on this matter... cool

In the meantime, one might try the RBE - Rainbow emulator for DOS ( http://rainbow-100.com/archives/73/ ). Although i doubt it's very compatible.

Code:
  The following Rainbow firmware (int 18H) functions are emulated by
          RBE:

               Function 00H,    Console output
               Function 02H,    Level 2 Console in
               Function 04H,    Level 2 Console Status
               Function 06H,    Level 1 Console in
               Function 08H,    Disable Cursor
               Function 0AH,    Enable Cursor
               Function 14H,    Write characters and attributes to screen
               Function 1EH,    Ring the keyboard bell

          Calls for any of the other functions available through int 18H are ignored.

( taken from RBE.DOC )

RBE requires an ANSI driver
Posted By: Lord Nightmare

Re: Requirements? - 05/06/12 01:55 AM

One of the issues with the rainbow is the z80a has no rom at all; its entire 64k address space is ram (62k shared with the 8088, and 2k dedicated for itself); because the z80 boots at 0x0000, I *assume* the shared ram is from 0x0000 to 0xF7FF and the dedicated ram is from 0xF800 to 0xFFFF; the RX02 floppy drive must connect via I/O, and the 8088 cpu has to have some way of holding the z80 at address 0x0000 using /HALT or /WAIT or /BUSREQ before it uploads code for it to run into the 8088 side of the shared ram.

Do we have schematics of the Rainbow on bitsavers or something?
EDIT: not on bitsavers, but here: http://www.os2site.com/dec/rainbow/doc2/index.html

LN
Posted By: R. Belmont

Re: Requirements? - 05/06/12 02:14 AM

Yes, the Z80 is not yet hooked up, at all.

Speaking of which, rfka01: do you have the original document that the "PC100 SYSTEM SPECIFICATION" is scanned from? The PDF has a washed-out stripe down the middle of page 25 which obfuscates some of the details of how the Z80 side works. Is it possible to get that rescanned?

ETA: L_N: the aforementioned page 25 tells (some of) the tale. The default bootup mode is "Z flip", where Z80 0x0000 is 8088 0x8000, and indeed if you boot the driver right now a working Z80 image is stored at 0x8000.

I don't understand how the 8088 holds/resets the Z80 prior to that image being present though. I/O port 0 on both CPUs is a latch and interrupt going to the other CPU, but I don't see anything that would cause a reset. Both IRQ and NMI on the Z80 image at 0x8000 echo whatever they see back through the latch and then HALT.

ETA 2: the latch interrupt is actually RST 30, which thins the plot a little (the code that jumps to appears to copy the RAM around a bit and turn off Z-flip), so that may be all that's necessary to boot the Z80.
Posted By: rfka01

Re: Requirements? - 05/06/12 08:43 AM

Hi,

this is the re-scanned page:

Page 25 re-scanned

Robert
Posted By: R. Belmont

Re: Requirements? - 05/06/12 03:13 PM

Perfect! Thanks.
Posted By: R. Belmont

Re: Requirements? - 05/06/12 09:19 PM

I got the Rainbow to go a bit further - the Z80 now boots up, copies it's boot image to private RAM, checksums it, and reports the correct checksum back to the 8088. So that gets us past that test, now we fail on error 10, which is "Video VFR" according to the manual. Appears that's the 60 Hz vblank IRQ...

For peeps following along at home, ftp://ftp.update.uu.se/pub/rainbow/doc/rainbow-docs/pc100tm1.pdf is the Technical Manual, which is quite a bit less error-prone and much better written than the System Specification.
Posted By: R. Belmont

Re: Requirements? - 05/06/12 09:42 PM

Ok, got VBL interrupt raise/clear working to its satisfaction.



In order, that's "printer port not working", "restored CMOS defaults" (sounds promising!), and "memory arbitration fault" (not sure what that means).
Posted By: R. Belmont

Re: Requirements? - 05/07/12 01:37 AM

Apparently nobody cares about this thing, but luckily it's interesting enough that I kept going anyway wink



I think it might actually boot once we get the keyboard to respond, but that's pretty much all my time for this weekend.
Posted By: R. Belmont

Re: Requirements? - 05/07/12 02:55 AM

Better Z80 control eliminates both the garbage and the "Z80 Response" error code. Also the keyboard error is different now, I don't know why smile

Posted By: Robbbert

Re: Requirements? - 05/07/12 03:23 AM

Originally Posted By R. Belmont
Apparently nobody cares about this thing.


No, we are watching good things happen. smile
Posted By: Duke

Re: Requirements? - 05/07/12 09:27 AM

You wrote something about the 8251 core needing interrupts, but the RXRDY and TXRDY pins seem to be implemented.
Posted By: ASH

Re: Requirements? - 05/07/12 10:04 AM

Originally Posted By R. Belmont
Apparently nobody cares about this thing, but luckily it's interesting enough that I kept going anyway wink


Somebody is always watching wink
Posted By: R. Belmont

Re: Requirements? - 05/07/12 12:02 PM

Duke: Yes, but there's no interrupt pin.
Posted By: Duke

Re: Requirements? - 05/07/12 12:22 PM

Yeah, because there is none on the 8251.



According to the technical manual RXRDY and TXRDY are connected to the 8088 interrupts.
Posted By: R. Belmont

Re: Requirements? - 05/07/12 12:43 PM

Ahh. That's handy then.
Posted By: rfka01

Re: Requirements? - 05/08/12 05:45 PM

Try pressing F3 at that stage ... that key is equivalent to "SetUp" on a real Rainbow and enters a special mode during normal operation.

Here it shows

Posted By: Bavarese

Re: Requirements? - 05/18/12 08:50 AM

Isn't that the place where some basic settings like serial bit rate, video inversion etc. can be made?

Don't have my DEC 100B right next to me to check, i only remember that mainly periperals were involved.

EDIT: the procedure is described on pages 37 - 52 of the Technical Manual mentioned earlier in this thread

ftp://ftp.update.uu.se/pub/rainbow/doc/rainbow-docs/pc100tm1.pdf

Originally Posted By rfka01
Try pressing F3 at that stage ... that key is equivalent to "SetUp" on a real Rainbow and enters a special mode during normal operation.

Here it shows

Posted By: rfka01

Re: Requirements? - 05/22/12 09:25 PM

I've taken apart a few machines to send ICs to a guy who'll try to read as many of them as possible.

I've used this opportunity to take a few more pictures, and in some cases re-read eproms.

Here are some pictures of the NCR DMV's keyboard

DMV Keyboard

Here are pictures and the ROMs of the Siemens PC-D's keyboard and harddisk controller

PC-D HD and keyboard

I'll add the rest when I get the results from this reading frenzy :-)

Robert
Posted By: R. Belmont

Re: Requirements? - 05/22/12 10:33 PM

What are the markings on the keyboard CPU? It's not quite legible in the picture.
Posted By: rfka01

Re: Requirements? - 05/22/12 10:50 PM

For the DMV, the big IC reads 006-00595 14 Motorola 8328

The Siemens PC-D has a Philips IC MAB 8035HL 6D8 DND 418 V1Y

Posted By: R. Belmont

Re: Requirements? - 05/22/12 10:51 PM

Sorry, I should have specified I meant the PC-D smile Thanks for listing both anyway!
Posted By: Bavarese

Re: Requirements? - 05/23/12 01:09 PM

It's quite sad: the diagnostic LEDs on my Rainbow show error 19 (0-64 K RAM failure on motherboard), and the VR201 monitor went up in black smoke - so i can't see anything.
Keyclicks are audible, though.

As i'd like to contribute: do we need additional ROM dumps or motherboard photographs of the DEC-100B - or it's extension cards?

It's revision 2 or 3 (sorry, the label is barely readable) with a German language rom and optional hard disc.

Addon boards in my system:
1) RD51 extension board (= floppy controller board?),
2) Ram expansion (with 4 DIP switches)
3) MIO card (= winchester addon card?)



Posted By: R. Belmont

Re: Requirements? - 05/23/12 02:37 PM

We have a "German-French-English" ROM right now, part numbers 23-022e5-00 and 23-020e5-00. If yours is another part, that would be interesting to get dumped at some point.

Lord_Nightmare just dumped the controller ROM from an LK201 which will help further the emulation smile
Posted By: Lord Nightmare

Re: Requirements? - 05/23/12 05:17 PM

Balrog did all of the heatgunning, soldering and leg-repair work, I just helped breaking apart the pcb to get half the chip out, prying the other half of chip until it came halfway out leaving a bunch of legs behind, and messing with the (repaired) chip until it dumped properly.

Also I think we're going to have a proper viking funeral for the LK201 which died for this purpose, involving relieving pent up frustration about how insanely difficult it is to repair shorted membranes on a keyboard whose membrane stack is plastic-peg-melt-fastened-together to the keys and metal plate with about 200 pegs, and whose pcb has razor sharp membrane contacts which shred the membrane traces when you pull them out. Funeral may also involve baseball bats. Video will be taken of the event for those unable to attend.

LN
Posted By: rfka01

Re: Requirements? - 05/23/12 05:25 PM

Looking forward to the footage ;-) and the files ripped from the poor beast
Posted By: rfka01

Re: Requirements? - 05/25/12 10:01 AM

I created a translation of the Wiki page for the PC-D ... while it's being reviewed it can be found here:

PC-D Wiki, currently being reviewed

Robert
Posted By: Bavarese

Re: Requirements? - 05/25/12 08:56 PM

OK. The checksums of the 3 EPROMs i dumped today are exact duplicates of those available as a download on "Drive W" (rainbow-100.com). The character rom is also identical. Sigh. :-)

@rfka : would you lend a fellow countryman your 100-B motherboard? Do you have a DEC compatible monitor?

I'd really like to peek on the data of the winchester drive (Seagate ST-412 MFM and therefore incompatible to modern computer hardware)...

Spent the evening trying to repair the broken MB (see post above), but gave up.

Originally Posted By R. Belmont
We have a "German-French-English" ROM right now, part numbers 23-022e5-00 and 23-020e5-00. If yours is another part, that would be interesting to get dumped at some point.

Lord_Nightmare just dumped the controller ROM from an LK201 which will help further the emulation smile
Posted By: rfka01

Re: Requirements? - 05/27/12 09:01 PM

I have scanned some service manuals of the Siemens PC-D

Siemens PC-D service manuals

As they are in German, I have extracted some pages and translated most of these. The archive contains a PDF with the excerpt and a Word document with the translation, it's best to read them side by side.

PCD translation

Robert
Posted By: rfka01

Re: Requirements? - 05/28/12 09:14 AM

Andreas, who's contributed to the M20 emulation progress, has dumped some more ICs from other PCs which I'm posting in the appropriate threads:

I've updated this archive with the contents of the 8741AD's contained in the NCR DMV mouse adapter, the mainboard and keyboard.

DMV ROM addendum updated 2012-05-28

The PCD ROM archive now also contains the contents of the 8741AD from the PC-D graphics board.

Andreas managed to read one of the PALs from the DEC Rainbow 100's graphics board, the other contained only zeroes or was protected. It's included here: more Rainbow files

Andreas could not read the various NEC 7220's

Robert
Posted By: R. Belmont

Re: Requirements? - 05/28/12 12:14 PM

Great! AFAIK the 7220 doesn't contain any ROM so you won't be able to read it anyway.
Posted By: rfka01

Re: Requirements? - 05/28/12 01:43 PM

The documentation is at least ambiguous, so I wasn't sure

Nec 7220 docs

Next to the 7220 on the DMV graphics boards is either a M1-76161-5, a M3-76161-5 or a N82S191N/K8340 ... are those RAM or (P)ROM IC's?

Robert
Posted By: R. Belmont

Re: Requirements? - 05/28/12 04:31 PM

82S191 is indeed a 16Kbit (2K bytes) bipolar PROM. Likely a font at that size.
Posted By: rfka01

Re: Requirements? - 05/28/12 08:29 PM

The alternative IC 82S191N was the lead to successfully reading the two PROMs from the NCR DMV Colour and Mono Graphics boards ... they're now included here

DMV ROM addendum ... updated 2012-05-28

Andreas now also was able to read the PALs from the Rainbow graphics board correctly, they're included here:

Rainbow ROM addendum - updated 2012-05-28

Robert
Posted By: Bavarese

Re: Requirements? - 05/29/12 09:32 AM

Are both graphics JED's identical?

RB 100 Graphics PAL#1.JED and
RB 100 Graphics PAL#2.JED have the same CRC [ 86CFB4BC ] in IZarc / the ZIP file.

A strange coincidence...
------------------------------------------------------
EDIT: apart from the JED, these 2 ROMs look new to me:

FILE ----- LAST BYTES ---------- ID / DATE (?)- ZIP-CRC:
B3-2.HEX = 383d 2e38 3908 4fa8 = "8.89" ------ 70dbb743
HD-2.HEx = 3135 2f31 3101 47a1 = "15/11" ----- 474d48dd

Posted By: rfka01

Re: Requirements? - 05/29/12 10:10 AM

Hi Bavarese, check your pm ...

Andreas, who did the dumping, was not sure if he was able to read the PALs properly - consider them "bonuses" to them ROM code ...

Robert
Posted By: rfka01

Re: Requirements? - 06/03/12 10:03 PM

I've updated this archive

PC-D HD and Keyboard

with the manual for the OMTI 5100 SASI=>MFM controller used in the PC-D

Robert
Posted By: Bavarese

Re: Requirements? - 06/06/12 01:03 PM

MESS and it's integrated debugger have already proved useful to me.

Unfortunately my grasp of C is weak (and the implementation of write-only and read registers at the same address with different semantics might be tricky)...

It looks as if the COMMUNICATIONS STATUS / CONTROL REGISTER 02 - - together with possibly less important registers (8,11, 27, 67, 50) are still unmapped in MESS(UI)145u7b.

Could be a problem, as the rainbow relies on the state of the MHFU ('massive hardware failure' watchdog) in bit 5. It must be somehow acknowledged by the 8088 and is triggered by the video processor.


P.S.: i just disassembled the boot rom with IDA 5 Freeware to find out what it does (below, feel free to change or improve it; IDA database included)...

https://dl.dropbox.com/u/37819653/RBLOW_v1_IDA5_free.7z

They used several fixed timing loops (which later had to be patched to higher values when the NEC V20 CPU came out).

Offsets are 072F and 0B36. Guess that's no problem for MESS, as it is cycle-exact...

Notes

- after reset, execution starts at pos.0 of the jump table (this redirects to $86)

- the CRC check of the ROM (possibly all 3) can be defeated by setting offset $303 to $00

- test routines for factory tests are implemented. When jumpers W13, W14 or W15 are set, bits 1-3 of register 0A (normally set at 1) go low. Code to evaluate these starts around offset $251.

An interesting feature, because diskette, video and printer signals can be routed to the serial port (if i read the manual correctly).

Is it difficult to get jumpers implemented?


-----------
':maincpu' (F40A6): unmapped i/o memory write to 0002 = F4 & FF
':maincpu' (F40A8): unmapped i/o memory read from 0002 & FF

000000A2: B0F4 mov al,0F4 ;""
000000A4: E602 out 02,al
000000A6: E402 in al,02
000000A8: A820 test al,020 ;" "

LATER
':maincpu' (F4154): unmapped i/o memory read from 0067 & FF
':maincpu' (F4962): unmapped i/o memory write to 0027 = 94 & FF
':maincpu' (F4964): unmapped i/o memory read from 0050 & FF
':maincpu' (F5434): unmapped i/o memory read from 0000 & FF
':maincpu' (F5D95): unmapped i/o memory read from 0008 & FF
':maincpu' (FE87A): unmapped i/o memory write to 0011 = 17 & FF

///////////////////////////////////////////////////////////////
[02] COMMUNICATIONS STATUS REGISTER - PAGE 154 (**** READ **** )
=> SHOWN IN 4-30; bits in 4-16 (page 154)

Used to read status of SERIAL modem, IRQ line of each CPU, and MHFU logic enable signal.

TABLE 4-16:
# VALUE
0 1 * COMM RI (represents the state of RING INDICATOR - RI)
1 2 COMM SI/SCF (state of SPEED INDICATOR LINE -or- SECONDARY RECEIVE LINE SIGNAL DETECT)
2 4 * COMM DSR (state of DATA SET READY)
3 8 * COMM CTS (state of CLEAR TO SEND)
4 $10 COMM RLSD (RECEIVE LINE SIGNAL DETECT)
5 $20 MHFU ENBL L (status of MHFU enable L)
6 $40 INT88 L (reflects status of INT88 L bit asserted by the Z80 to interrupt the 8088)
7 $80 INTZ80L (reflects the status of the INTZ80L bit asserted by the 8088 to interrupt the Z80A)
///////////////////////////////////////////////////////////////
[02] COMMUNICATIONS CONTROL REGISTER - PAGE 155 (**** WRITE **** )
=> SHOWN IN 4-31 and the bits in 4-17 = PAGE 155
Used to set / write MODEM (SERIAL) + DIAGNOSTIC LEDs :

TABLE 4-17:
# VALUE
0 1 COMM SPD SEL H (controls SPEED SELECT line on COMM port)
1 2 COMM SRTS H (controls SECONDARY REQUEST TO SEND line on COMM port)
2 4 COMM DTR L
3 8 COMM RTS
4 $10 LED D6 LSB (wrong) - D3 !
5 $20 LED D3 (wrong) - D6 !
6 $40 LED D4
7 $80 LED D5

///////////////////////////////////////////////////////////////
2 DIAGNOSTIC 8 BIT REGISTERS:
///////////////////////////////////////////////////////////////
[0A] DIAGNOSTIC WRITE REGISTER - PAGE 153 ( *** WRITE ONLY *** )
=> SHOWN IN 4-28 and the bits in 4-10 to 4-14

Used during diagnostic testing to control and read the status of various system FX.

TABLE 4-10:
# VALUE
0 1 ZRESET (1 resets the Z80 from the 8088 processor side; active at power-up)
1 2 DISPLAY BLANK (blank = 0)
2 4 GRF VID SEL
3 8 PARITY TEST (1 = high enbales testing of the parity circuit on optional MEMORY BOARD)
4 $10 DIAG LOOPBACK (0 = cleared at power up, RX50 and DC12 video circuit testing thru printer)
5 $20 PORT LOOPBACK (COMM, PRINTER and KEYBOARD tests)
6 $40 PROGRAMM NVM (when 1, this allows data to be written into the NVM)
7 $80 RECALL NVM (read / recall data from the NVM)

NOT SHOWN : TABLES 4-11 to 4-14 show various LOOPBACK routings to serial
///////////////////////////////////////////////////////////////
[0A] DIAGNOSTIC READ REGISTER - PAGE 153 ( *** READ **** )
=> see TABLE 4-29 and for the bits see 4-15

TABLE 4-15:
# VALUE
0 1 ZRESET L (represents the state of bit 0 of the 8088 diagnostic write register)
1-3 - state of W13, W14 and W15 MANUFACTURING TEST JUMPERS (normally high = 1)
4 $10 DIAG LOOPBACK H (diagnostic loopback H, state of bit 4 of 8088 diag.write register)
5 $20 PORT LOOPBACK H (PORT loopback H, state of bit 5 of 8088 diag.write register)
6 $40 PROGRAMM NVM (program NVM : state of bit 6 of 8088 diag.write register)
7 $80 RECALL NVM (recall NVM: state of bit 7 ...)


EDIT: i detest un-searchable PDFs, so i typed in this textual representation with page references to the technical manual (pc100tm1.pdf). BTW: is there a programmer's manual for the Rainbow?
Posted By: R. Belmont

Re: Requirements? - 06/06/12 02:22 PM

0.145u7 predates all of the work I put into the Rainbow driver; you should get 0.146 to be in sync with the current state.
Posted By: rfka01

Re: Requirements? - 06/11/12 11:31 AM

I finally got round to tinkering with my NCR DMV's ... the bad news is, that both colour machines appear to be dead. The good news is that I was able to cobble together a working machine that accepts all four operating systems: CP/M-80, CP/M-86, MS-DOS and CP/M-68K

I've scanned two further manuals and combined them with a publicly available one, so in this archive

NCR DMV System Technical Manuals

you can find three of the four System Technical manuals (for Hardware, CP/M-80 and CP/M-86). Apart from Hardware descriptions, there's also programming info and commented BIOS disassemblies/listings.

Robert
Posted By: Bavarese

Re: Requirements? - 06/12/12 04:24 PM

Added a lot of flag descriptions to my disassembly, found out how string sequences are encoded (as a table in RBHIGH.16K, from $c5 to $229), kicked unwanted AT references and much more.

Still, a lot of functions in the initial jump table remain unclear. And there is also the occasional jump to the high ROM.

HTML output and IDA source is included, improvements and constructive criticism are welcome.

https://dl.dropbox.com/u/37819653/RBLOW_V2_IDA5_free.7z
Posted By: Bavarese

Re: Requirements? - 06/29/12 09:14 AM

The third revision of my ROM disassembly.

Most fatal (and non-fatal) error messages from the high rom were decoded and are present in clear text now (for example, 33 Contention).

Also added descriptions of some video and keyboard registers where it made sense (to me) grin

Disassembly of Rainbow LOW ROM 16K v3

[IDA Freeware v5 source included]

EDIT: found a link to an OCR'ed version of the Rainbow 100 PC100 System Specification (March 1983). Hope it isn't already linked elsewhere:

http://archive.org/details/dec-rainbow-100-specs

Looks quite useful when read together with the technical manual (interrupt tables, some video registers...)
Posted By: Justin

Re: Requirements? - 06/29/12 02:23 PM

Yep I uploaded that from here so it doesn't get lost smile Will try and get more stuff up as I get time.
Posted By: rfka01

Re: Requirements? - 06/29/12 06:12 PM

I dug out some folder containing copies of more NCR DMV system related information, some of it might already be contained in the manuals I've posted so far, but there is definitely some new information in English.

NCR DMV System Info

Robert
Posted By: rfka01

Re: Requirements? - 07/24/12 11:38 PM

I like the way Lord Nightmare implemented the status LED's in the VK100 driver ... it would be great to have the onboard error LED's of the DMV, PC-D and Rainbow like this as well.

Robert
Posted By: Lord Nightmare

Re: Requirements? - 07/25/12 04:39 AM

The layout was done by Micko; I literally just copied the layout from the vt100 that he did, edited it a little bit, and hooked it to the vk100.

LN
Posted By: rfka01

Re: Requirements? - 08/05/12 03:32 PM

Thanks for the changes to the DMV driver, Sandro Ronco, much appreciated smile

Robert
Posted By: Bavarese

Re: Requirements? - 08/30/12 01:44 PM

I was able to find some in-depth information on the LK201 keyboard, as well as the DEC mouse used with Windows 1.0 on DEC Rainbow 100 (also on later DEC VAXMates).

Linux people already have a working LK201 and LK401 keyboard, as well as a mouse driver (below, though i can't tell if it's of use) :-)

The DEC hockeypuck mouse (VSXXX-AA and -GA) had a proprietary, 7 pin 'PS/2 style' adapter and had to be plugged into the serial printer port of the DEC Rainbow 100 (via another adapter).

It was in fact a "200 counts per inch" serial mouse (4800 bps, 1 start bit, 8 data bits (LSB first), 1 parity (ODD), 1 stop bit, half-duplex) with a SIGNETICS SCN2661.

There are probably some similarities to Logitech mice (rumours say the Logitech C7 serial mouse for PC could be switched into a DEC compatible mode, at least for AutoCAD, and the DEC VAXMate mouse could be switched into a PC compatible mode via MOUSE.COM and/or MOUSE.SYS).


--------------------------------------------------------------
APPENDIX B : LK 201 Keyboard specification
(pages 357 +)

APPENDIX C : Mouse sub system; chapters C3 => C-12
(pages 403 and on)

HTML index was easy to find, only the original, 120 MB PDF was not (working mirror below):

VCB02 Video Subsystem Technical Manual
Company: Digital Equipment Corporation
Part: EK-104AA-TM-001
Date: 1987-02
Keywords: LK201


HTML INDEX:
http://manx.classiccmp.org/details/1,21

SLOW DOWNLOAD (119 MB!): http://z80cpu.eu/mirrors/oldcomputers.dyndns.org/rechner/dec/manuals/decimages/104aatm1.pdf

--------------------------------------------------------------
"News about proprietary mice made by Digital Equipment Corporation"

http://web.archive.org/web/20080509094502/http://www.cs.utk.edu/~shuford/terminal/dec_mouse_news.txt
--------------------------------------------------------------
DEC LK201 and LK401 keyboard driver for Linux, based on sunkbd.c (C) by Vojtech Pavlik

(DEC Rainbow 100, also for DECstations + VAXstations)

http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/drivers/input/keyboard/lkkbd.c
--------------------------------------------------------------
Bits of information from PAGES 53 - 70 of

http://www.bitsavers.org/pdf/dec/ethernet/EK-DEPCA-PR-001_Apr89.pdf

The mouse has two operating modes, prompt mode and incremental
stream mode. In prompt mode, which is the powerup default, the mouse generates a report in response to a request mouse position command.

In incremental stream mode, whenever the mouse moves it generates a report of that movement. It also reports a change in button position since the last report. No report is generated when the mouse is motionless and no buttons have been changed

The mouse can transmit two reports, a 3-byte position report and a 4-byte self-test report.

Table 3-1 Mouse Command Summary
ASCnValue Hex Value Function

D 44H Prompt Mode
R 52H Incremental Stream Mode
P 50H Request Mouse Position
T 54H Invoke Self-test
Zx 5AH :xx Vendor Reserved function

- - - - - - - - - - - - - - - - -
EDIT: "GPL Driver for DEC VSXXX-AA and -GA mice by Jan-Benedict Glaw <jbglaw@lug-owl.de>"

http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/drivers/input/mouse/vsxxxaa.c
Posted By: R. Belmont

Re: Requirements? - 08/30/12 02:16 PM

Information hasn't been the bottleneck on Rainbow, the "there's only one of me" has been ;-)
Posted By: rfka01

Re: Requirements? - 10/14/12 08:46 AM

The DMV driver used to be able to load Teledisk images (they wouldn't boot, but load correctly) through the TAB menu.

They now give the "Error:" message.

mess64 dmv -listmedia shows, that only .mfi disk images are supported.


Where in MESS is the colour of a monochrome display set?
Posted By: Micko

Re: Requirements? - 10/15/12 07:33 AM

Please note that floppies are still work in progress.

Thing is that conversion for existing file formats to internal representation is still not done for all formats, and that is thing that can be tricky in some moments, but also note that it would make irelevant source format and it could be possible to save file in any file format that support save in future, with old floppy core that was not possible.

Some driver support is now lost due to a conversion to new core, but it should get us better future for sure.
Posted By: Lord Nightmare

Re: Requirements? - 12/12/12 01:26 AM

Originally Posted By Lord Nightmare
The layout was done by Micko; I literally just copied the layout from the vt100 that he did, edited it a little bit, and hooked it to the vk100.

LN


... And I just realized I need to do it again for the vt101/102/131 where the last 4 LEDs have different labels than the standard vt100 (I think the keyboard pcb is the same part though, just has a different overlay sticker on the LEDs? without the 101/102/131 tech manual or MP sheets it is hard to tell...)

LN
Posted By: Bavarese

Re: Requirements? - 12/17/12 12:17 PM

Oops, DEC100B emulation in MESS 1.47u3 requires the LK201 keyboard dump now (23-00159-00.bin)

Is the ROM still off-limits for end-users?

I own the machine, but don't want to pry the old keyboard apart frown


On another note, i found some (alas blurry) screenshots of an actual VT101 keyboard here:

http://deskthority.net/photos-videos-f8/digital-equipment-vt101-t2824.html

http://deskthority.net/resources/image/3681

http://deskthority.net/resources/image/3683

http://deskthority.net/resources/image/3684

Hope this helps.
Posted By: R. Belmont

Re: Requirements? - 12/17/12 03:27 PM

We can't post ROMs here, but that particular ROM has been available from fine illegal ROM sites for the last 3 months. Google is your friend.
Posted By: Waremonger

Re: Requirements? - 12/18/12 05:18 AM

Originally Posted By Bavarese
On another note, i found some (alas blurry) screenshots of an actual VT101 keyboard here:

Wow, that brings back some memories. I used to use these at work in the mid-80's.
Posted By: Bavarese

Re: Requirements? - 01/30/13 07:02 PM

The 2013 version of my Rainbow disassembly (HTML + IDA 5 freeware source included).

https://dl.dropbox.com/u/37819653/Jan-2013_DISASSEMBLY.zip

Documented & located a bunch of internal routines, for example

$1e15 - ROM_ConsoleLev2In
$1e01 - ROM_ConsoleLev2Stat
$1e24 - ROM_ConsoleLev1In
$001e - ROM_DisableCursor
$0021 - ROM_EnableCursor
$1e49 - ROM_InitVectors
$1dfa - ROM_ReturnClock
$1ebf - ROM_SetLeds (keyboard LED positions documented)
$1ec3 - ROM_ClearLeds
$1ecc - ROM_FastVideo (with parameters!)
$1f09 - ROM_InitToNVM
$1f0c - ROM_RawKbdData
$1f23 - ROM_RomVersion
$1f66 - ROM_ChangeVectorMap
$1fc2 - ROM_RingBell
$1fc8 - ROM_GetSet7or8

(just search for :1DBA in the HTML output)
Posted By: Bavarese

Re: Requirements? - 06/11/13 11:58 AM

Rainbow-100 B low rom disassembly updated
Here ist the June 2013 edition of my low ROM disassembly (documented IDA 5 Freeware source and HTML).

https://dl.dropboxusercontent.com/u/37819653/June-2013_DISASSEMBLY.zip

Managed to find out more on how DC011 and DC012 display controllers are initialized (search for DC011, DC012 and INIT_VIDEO_HW). NVM handling is better documented (-> keyword NVM in HTML).

Also, it is now clear how option boards (the RAM board for 128 - 896K, as well as the communication board, which has a DMA and a non-DMA mode) are detected: via interrupts (-> keywords: OPTION or ENABLE_RAM_BOARD_DETECTION)

It's a pity that high intensity and underline, blink, reverse, as well as 80 / 132 column mode (with different dot pitches) aren't emulated yet. VT100 emulation seems a clever decision, but i can't imagine how the more exotic modes of the real hardware could be emulated (BIOS unsupported 48 line modes like http://rainbow-100.com/archives/154/ OR : SQUINT from Latrobe http://www.classiccmp.org/rainbow/files/goodnight/LATROBE/s/squint.arc - will provide a photo later)

BTW, the pc98gdc.c / PC98 MESS driver seems to implement the NEC 7220 display controller used in the color graphics extension (required for the early Windows 1 DEC released).

-----------------------------------------------------------
I was asked to document the 4 test jumpers present on the 100-B motherboard.

W13, W14 and W15 manufacturing test jumpers are represented by bits 1,2,3 of Diagnostic Read Register $0a

Jumper W18 pulls DSR line LOW when set (bit 7 of Status Read Register $11). It is possibly the 'unknown' jumper near the Z80 (requires verification).

Example from the low ROM disassembly:

seg000:0DEF test al, 80h ; W18 jumper / DSR (bit 7)
seg000:0DF1 jnz short loc_DE1

Code:
Location on the 100-B motherboard  : 

      [W13]   
                [W 14 ]
[ 74 LS 245 ]
		[W 15 ]


                  [UNKNOWN JUMPER]

--------------------

   Z 80
  
--------------------


I wish someone could add jumpers and accurate NEC V20 (80186+) emulation - the latter was one of the more affordable upgrades on the 100-B. Note that the original V20 patch published on Jeff's 'DRIVE W' introduces serious timing issues.

My real hardware quickly got a worn out EPROM socket when i tried these - and other - hacks smile

Posted By: Lord Nightmare

Re: Requirements? - 06/13/13 02:29 PM

Speaking of Rainbow, I dumped the two PROMS and two PALS from one of the Rainbow's video boards (specifically, board "5015687 01" with the upd7220D-1 on it) rfka01 lent me.

These will be added to the driver shortly.

P.S. if you wore out the eprom socket, grab a soldering iron, a soldapult and some flux, and replace them; I suggest using dual wipe sockets from digikey, and to prevent this happening in the future, stack an extra socket on top of each one in the board, and use that extra socket when inserting/removing chips. (hence, if a socket fails, you can pull it out of the other socket, no desoldering needed)

LN
Posted By: Bavarese

Semi graphics on the Rainbow-100 - 08/02/13 10:50 AM

Hi there,

i am currently experimenting with semi graphics on the Rainbow-100. A modified character ROM and a simple QBASIC program (to read BMPs) are sufficient to achieve:

264 x 72 (264 x 96) resolution in 132 x 24 mode
140 x 144 (140 x 192) resolution in 70 x 48 mode (custom mode of DC011/DC012)

Resolutions in brackets use a 2x4 character set instead of 2x3.

As you can see in the image, you can even mix text and graphics - normally impossible on the Rainbow laugh

https://dl.dropboxusercontent.com/u/37819653/Rainbow-100%20Semi%20graphics.jpg

I know it is an old trick, but the technique (and the source) could be adapted to other systems with more horsepower and screen RAM.

---- Back to our main topic: the current VT100 (or Rainbow?) driver does not allow reverse character attributes ($ef000 attribute RAM). Is this a bug?
Characters above $80 display in reverse, though.

To be more precise, even the error messages (shown when deliberately booting the 'non working' driver) have active reverse, bold, and blink attributes - if i remember correctly frown

The character space needed could be reduced easily if not only line, but character attributes also worked.

Any hints, suggestions or ideas?

Posted By: R. Belmont

Re: Semi graphics on the Rainbow-100 - 08/02/13 01:44 PM

It's quite possible attribute RAM isn't fully supported; L_N would know more about that since it's borrowed from the VT100.
Posted By: Lord Nightmare

Re: Semi graphics on the Rainbow-100 - 08/02/13 05:31 PM

Yeah the video stuff in vt100 is missing a number of graphics features (evident on the setup screens as well); I didn't write that code though, I think that was Micko or Judge.

LN
Posted By: Bavarese

Re: Semi graphics on the Rainbow-100 - 08/13/13 09:43 AM

I looked into vtvideo.c, but don't want to interfere with the VT100 code (no experience and no way to test on a live machine).

That said, i recently added 3 of the 5 character attributes necessary (reverse, blink, underline) - only for RAINBOW_VIDEO.

Bold (intensity) and soft scrolling are not as easy to implement.

Additional to the 48 line mode (now also implemented & not present on the VT-100) there are possibly some undocumented DC012 pokes - see below.

Any info would be appreciated.


https://dl.dropboxusercontent.com/u/37819653/SQUINT_Disassembly__POKES.jpg
(excerpt from fun program, compresses image to a quarter of the normal screen size on a real DEC-100 B)

---------
Attached, you see a screenshot of a VR201 (orange-black) monitor connected to the Rainbow-100.

The combination of different attributes (bold + reverse characters on reverse base video) is a bit tricky to emulate correctly.

https://dl.dropboxusercontent.com/u/37819653/rainbow-1024x768.jpg

Question: what's the proper way to configure the palette to emulate different VR201 phosphor types (orange, white, ...)?
Posted By: rfka01

Re: Semi graphics on the Rainbow-100 - 08/22/13 01:50 PM

This is the doc for the WD2793 Floppy disk controller used in the Siemens PC-D

https://dl.dropboxusercontent.com/u/55419307/WD2793%20datasheet.pdf

It would be great if the PC-D could benefit from the recent changes to the 80186 driver and be broken out from PC compatibles into a seperate driver (it uses no standard PC bus and can not boot from generic MS-DOS floppies).

Robert
Posted By: R. Belmont

Re: Semi graphics on the Rainbow-100 - 08/22/13 02:40 PM

The WDx7xx is emulated to a boots-copy-protection level of detail, so no datasheets are necessary smile
Posted By: rfka01

Re: Requirements? - 08/22/13 03:50 PM

In the TRS-80 thread Robbbert mentions that

Quote:
I've had problems using wd_fdc as well. In my case (2 different drivers), firstly 0xd0 is sent (which seems to work), followed by 0xc0, which causes the fdc to stop responding, returning status 0x81 forever. I've been patiently waiting for the author of the code to fix it, but nothing so far.

I should point out that using WD1772 works fine, but 1793/2793 etc does not.


... the data sheet mentions a fundamental difference in the xxx3 models to the other chips, so I thought this might help smile
Posted By: Bavarese

Re: Requirements? - 09/18/13 01:27 PM

I have spent considerable effort into improving 'rainbow.c' and 'vtvideo.c' now. A bezel with nice LEDs is there and RAM up to 896 K is recognized by the native BIOS.

Still, error messages 13 and 50 are beyond my grasp.
Is there hope for a working keyboard any time soon?

I am willing to debug, too smile

Apart from the keyboard, what steps will have to be taken next? Is it the floppy or the not-yet-existing hard disc?
Guess the non-standard layouts could cause problems.

P.S.: i know nothing about slot devices, so i went to implement addon hardware via DIP switches. Hope no one bothers.
Posted By: Duke

Re: Requirements? - 09/18/13 04:29 PM

We do bother, because someone will eventually have to clean that up using slot devices, so better do it right from the start. There is lots of legacy stuff still in MESS and we don't want to add more.
Posted By: rfka01

Re: Requirements? - 11/12/13 06:13 PM

Bavarese mentioned in the shoutbox that he'd like to get BIOS dumps for the Turbow-286 accelerator card for the Rainbow. I've contacted Jeff Armstrong who admits to owning one smile Let's see if he can help.

In the meantime, there are pictures of this beast here:

http://archive.is/50OxY


Robert
Posted By: R. Belmont

Re: Requirements? - 11/12/13 06:15 PM

Wow, that thing really is a beast smile
Posted By: rfka01

Re: Requirements? - 11/14/13 07:25 AM

Jeff Armstrong got back to me - he'll dig out his turbow-286 and dump its ROMs.

In the meantime he sent me a real gem - the ROMs for the DEC Rainbow 190, a machine for which the only information on the 'net seems to be "it's rare".

https://dl.dropboxusercontent.com/u/55419307/rainbow_rom190.zip

Its secret seems to be (quoting Jeff):

Quote:
"The Rainbow 190 has _zero_ hardware differences from the 100B. If MESS can emulate the 100B, it just needs the 190's ROMS to emulate it as well. "


and later

Quote:
"I've attached the ROM dumps for the Rainbow 190. These should work just fine on a Rainbow 100B emulator in theory. They correspond to Rainbow firmware version 5.05A, whereas normal 100Bs use firmware version 5.03A. I'm not sure what's different, and I doubt anyone remembers anymore. I had some trouble with the 190's power supply, so I think I'll wait until tomorrow to figure out which Rainbow has the Turbow card (I have quite a few Rainbow's) and to subsequently dump the ROMs. I don't usually use the Turbow because I suspect it is providing too much load on the aging motherboards it's attached to.

I'll also be posting the ROM dumps to rainbow-100.com when I get around to it."


Robert
Posted By: rfka01

Re: Requirements? - 11/17/13 09:53 PM

News from Jeff Armstrong:

Quote:
I'll have to look at the 190 ROMs, but I'm pretty sure they're unlabeled. In the meantime, I was able to transplant the Turbow-286 card and ROM into another Rainbow and managed to get the system to boot (still having serious issues, though).

I've attached the two ROM dumps. I'm pretty sure that ROM1 is the stock 100B ROM, although my system has a ClikClok installed in between ROM1 and the board (I doubt that'd make a difference in the ROM dump). ROM0 is labeled: "TBSS 1.3" on line 1 and "3ED4" on line two (a checksum perhaps?).

I do have hi-res versions of the Turbow pictures somewhere. I'll have to look, but they should be accessible via the gallery I host. The chips aren't overly interesting, except that there does appear to be a GAL, which will make emulating it a pain. I remember reading that one of the chips, a 286-to-8088 adapter chip, was quite exotic at the time.

I'll let you know when I find the pictures and check for Rainbow 190 ROM labels.


https://dl.dropboxusercontent.com/u/55419307/DEC%20Rainbow%20turbow-286.zip
Posted By: rfka01

Re: Requirements? - 11/20/13 09:10 AM

With the Rainbow driver, ScrLock does not switch between partial/full keyboard emulation, so Shift-F3 always hard resets the machine. On a real Rainbow, Shift-F3 would enter the configuration menu.

Robert
Posted By: R. Belmont

Re: Requirements? - 11/20/13 01:00 PM

Something just occurred to me: have you done anything locally to emulate the Rainbow keyboard? If not, it doesn't exist and that's why the emulated machine can't be interacted with.
Posted By: rfka01

Re: Requirements? - 11/20/13 01:41 PM

RB, the DEC LK201 keyboard is integrated - I think LN dumped its ROM and included the keyboard driver with the Rainbow.
Posted By: R. Belmont

Re: Requirements? - 11/20/13 02:41 PM

It's integrated but doesn't do anything. The ROM we have is for a version that we don't have schematics for, and I'm not the greatest at figuring out keyboards from MCU code.

I'll take another whack at it soon, otherwise maybe the guys who *are* good at that stuff (Judge and Curt) will get bored and check it out ;-)
Posted By: Lord Nightmare

Re: Requirements? - 11/20/13 07:15 PM

Its possible I might get hold of a dead LK201 red LED keyboard (the one we DO have schematics for) sometime within the next 6 months or so.

The current dump is from the later cost-reduced green LED version.

LN
Posted By: Darkstar

Re: Requirements? - 11/21/13 10:21 AM

Regarding the DEC Rainbow, this just arrived on BitSavers yesterday:

http://bitsavers.trailing-edge.com/pdf/dec/rainbow/MP01722_PC100-B_Rainbow_Schematic_Jul84.pdf
Posted By: R. Belmont

Re: Requirements? - 11/21/13 12:52 PM

Yeah, but those schematics include neither version of the LK201, unfortunately.
Posted By: rfka01

Re: Requirements? - 11/21/13 04:37 PM

I think the document is a great find because it covers the Rainbow 100-B which we have the ROMs for.

Posted By: rfka01

Re: Requirements? - 11/21/13 10:39 PM

I wrote to Jeff Armstrong about the LK201 ... and he replied:

Quote:
"I'm not personally aware of differences in LK201 keyboards. In my experience, as long as the business end of the connector is compatible, it hasn't mattered. In fact, I often use LK401 keyboards with my Rainbows just because they're considerably smaller.

LK keyboards have been emulated before, I believe. You might want to look at the SIMH package. There was a gentleman whose name eludes me at the moment who managed to create a DEC Pro/350 emulator derived from SIMH package. I would guess he had a reasonable simulation of the LK series. HOwever, I would not be surprised if they were emulating the serial LK interface rather than the internals of the LK itself."


The emulator he mentions now is really interesting and can be found here ...

http://xhomer.isani.org/xhomer/

the machine would make a nice addition to MESS.

Robert
Posted By: R. Belmont

Re: Requirements? - 11/21/13 10:48 PM

Correct, the LK201 is the same from the machine's POV, but this is Sparta, err, MESS, and the internals of the original and cost-reduced models are quite different (totally different CPU families, key matrix wiring, and everything else).
Posted By: rfka01

Re: Requirements? - 11/21/13 11:22 PM

Yeah, I know and told him ... nonethless, there are some gems in that sourcecode archive smile

Posted By: R. Belmont

Re: Requirements? - 11/22/13 12:42 AM

Yeah, the info on the Pro/350 is definitely good to have smile
Posted By: Al Kossow

Re: Requirements? - 11/22/13 04:28 AM

I mentioned xhomer on the mess mailing list on Oct 23
Posted By: rfka01

Re: Requirements? - 11/22/13 08:28 AM

Where can I subscribe? Or do, to quote Augusto, "devs have all the fun"? smile
Posted By: rfka01

Re: Requirements? - 11/22/13 11:04 PM

More info from Jeff Armstrong:

Quote:
From your screenshots, it appears you're receiving a few Main Board errors
at boot. I'm not sure if you guys are aware, but the Rainbow's startup tests are quite particular about timing. The tests expect a cycle-perfect 8088, and they fail if they encounter anything else. A good example is replacing the CPU with an NEC V20, a pin-compatible chip with the 8088. The V20, though, is slightly faster, and it leads to some serious failures when booting. Therefore, some ROM modifications are necessary to get the chip to work. Have a look at:

ftp://ftp.update.uu.se/pub/rainbow/doc/v20prom.txt

While this isn't exactly the same scenario, it provides an example of the pickiness of the Rainbow tests. Additionally, talking with my father (one of the Rainbow's engineers), he pointed out that there are a significant number of "no-ops in the ROM to account for timing issues during self-tests." I'm not sure how accurate the 8088 emulation in MESS/MAME is, but it might lead to issues on the Rainbow.

-Jeff


Seems that FTP server has gone missing ... the document's here, though ...
https://dl.dropboxusercontent.com/u/55419307/v20prom.txt
Posted By: Bavarese

Re: Requirements? - 11/23/13 12:02 AM

I have updated my ROM disassemblies. The Language ROM is also contained, and most of the functions are now known -

https://dl.dropboxusercontent.com/u/37819653/DEC_100B_ROM-DISASSEMBLIES_Nov2013.zip

Concerning the NEC V20 upgrade and hard coded CPU loops. I suggested alternate (better) patch values in my 6th, recent source submission (for 26365) smile
Problem is: the machine i tested it on is a methusalem. Nobody knows how far it is off-spec.


It's really, really time we make progress with the emulation.

Recently an administrator talked about hardware failures. First, the hard discs fail. Then the PSUs. Then the motherboards.

My machines (have 2) seem to take the opposite direction...

-- screenshots from MESS with latest patches:
https://dl.dropboxusercontent.com/u/37819653/keyboard_selector.png

https://dl.dropboxusercontent.com/u/37819653/Rainbow_boot_selector.png

Finally, most if not all attributes work, VT-100 code could benefit from this.

Pokes to obtain these (not an official patch of course):

Code:
Rainbow.c - near line 310
	UINT8 *rom = memregion("maincpu")->base();

// Test-DEBUG:	rom[0xf5a14]=0xeb; // kill keyboard test result (=>ERROR 50)

// Patches to access international keyboard selector
rom[0xf4174]=0xeb; // jmps  RAINBOW100_LOGO__loc_33D
rom[0xf4175]=0x08; // 

rom[0xf4363]=0x90; // NOP out :   0363 WAIT_FOR_BIT3__loc_35E  
rom[0xf4364]=0x90; //             (do not wait for ??)

// *** UNCOMMENT TO SHOW BOOT SELECTOR:
// rom[0xf4384]=0xeb; // JMPS  to  BOOT80 ( selector )  

Posted By: rfka01

Re: Requirements? - 11/23/13 12:19 AM

Looks great, congrats!
Posted By: Bavarese

Re: Requirements? - 11/29/13 03:26 PM

The Rainbow-100 boots now! See attached picture of the Diagnostic Disk - live from the emulator.

https://dl.dropboxusercontent.com/u/37819653/Diagnostic_Disc_Menu.jpg

Tests are capable enough to reveal very subtle emulation bugs - and they do ;-)

Other CP/M or DOS (2.x) disks begin to boot, but soon hang (8088 HLT and / or Z80 HLT). In fact, the Diag Disk is the only one booting.

Is anybody willing to lend a hand? Need help with slot devices and the debugging of the Z80 or 8088 loaders in the context of MESS.

Currently, my code is not mature enough to submit to SVN. A hack to fill the keyboard buffer must be used. Most progress has been made in the field of the WD17xx hookup.

The processor flags INT88L + INTZ80L could still be wrong (these states are reused elsewhere).

Code:
// 8088 reads port 0x00. See page 133 (4-34)
READ8_MEMBER(rainbow_state::i8088_latch_r)
{
//    printf("Read %02x from 8088 mailbox\n", m_8088_mailbox);
	m_i8088->set_input_line(INPUT_LINE_INT0, CLEAR_LINE);

	INTZ80L = false; // WAS:  INT88L = false;
	return m_8088_mailbox;
}

// 8088 writes port 0x00. See page 133 (4-34)

// Interprocessor interrupt from the 8088 CPU. The vector placed 
// on the bus is F7 (hex) which causes a 
// RST 30 instruction to be executed in interrupt mode 0.
WRITE8_MEMBER(rainbow_state::i8088_latch_w)
{
//    printf("%02x to Z80 mailbox\n", data);
	m_z80->set_input_line_and_vector(0, ASSERT_LINE, 0xf7);
	m_z80_mailbox = data;

    INTZ80L = true;
}

// Z80 reads port 0x00
// See page 134 (4-35)
READ8_MEMBER(rainbow_state::z80_latch_r)
{
//    printf("Read %02x from Z80 mailbox\n", m_z80_mailbox);
	m_z80->set_input_line(0, CLEAR_LINE);

	INT88L = false; // WAS: INTZ80L = false;
	return m_z80_mailbox;
}

// Z80 writes to port 0x00 - see page 134 (4-35) of TM.
WRITE8_MEMBER(rainbow_state::z80_latch_w)
{
	//    printf("%02x to 8088 mailbox\n", data);
	m_i8088->set_input_line_and_vector(INPUT_LINE_INT0, ASSERT_LINE, 0x27);
	m_8088_mailbox = data;

	INT88L = true;
}
Posted By: rfka01

Re: Requirements? - 12/01/13 11:28 AM

Here are pictures of the NCR DMV's diagnostic module which I don't own ... I've contacted the guy (again) ... maybe he's willing to dump the ROM contents.

http://www.flickr.com/photos/50322765@N04/5012848897/in/photostream/

Robert
Posted By: rfka01

Re: Requirements? - 12/02/13 11:32 PM

Sometimes small wonders happen ... I was given the DMV diagnostic module by a guy who used to work for NCR ... he has already ditched the module case, but miraculously kept the PCB.

This archive contains the dumps of the two EPROMS.

DMV Diagnostics module

The DMV is a highly modular computer - the mainboard has 7 (or max. 9) slots into which massive modules are plugged. You can see the mainboard and modules here:

NCR DMV pictures

Everything, from serial ports, a RTC, mouse adapter to memory expansions gets plugged into those slots in the back.

So the DMV would benefit massively from slot-ifying the driver.

I've prepared two files that could, once they're filled with actual code, reside in emu/bus/dmv ... one is dmvbus.c, the other is dmvdiag.c, both contained in the above archive. At the moment they only contain ASCII graphics of the bus connector resp. the PCB layout of the diagnostics module.

Also included is the PDF about the diagnostics module from the documentation and a picture of the PCB.

Robert

Posted By: R. Belmont

Re: Requirements? - 12/20/13 03:33 AM

Bavarese: most of your submitted patch was applied. The keyboard hack was more gross than I wanted to deal with; I will attempt to get the LK201 to work correctly instead, and failing that do the keyboard hack "correctly": inside dec_lk201, without ROM patching.
Posted By: Bavarese

Re: Requirements? - 12/20/13 03:50 PM

Ok, accepted. Thank you very much.

Hope my keyboard mappings help a bit.

I still think the 8048 version and the 6805 version do not differ too much in terms of the wiring. Found 2 tables in the 6805 ROM (named 23-00159-00.bin) that look like the mapping i typed in on the basis of the official 8048 specs.

https://dl.dropboxusercontent.com/u/37819653/TABLE%202%20vs%20TABLE%201.png
(left: TABLE 1 - middle: TABLE 1 compared to TABLE 2
- right: decoding of KBD02 according to official specs)

Highlighted is a bunch of 16 bytes (one keyboard line?).

Table 1 begins at offset $0e2e
Table 2 begins at offset $0f4e
in ROM 23-00159-00.bin

Each table has a length of 288 bytes (18 KBD lines x 16).

Also disassembled it (code start $100), here is the result (including notes):

https://dl.dropboxusercontent.com/u/37819653/6805.txt

This was also helpful
https://dl.dropboxusercontent.com/u/37819653/KEY_GROUPS_AND_CODES.png

smile
Posted By: R. Belmont

Re: Requirements? - 12/20/13 04:06 PM

Great, thanks for the info on the tables! That should make it easier to figure out how the 6805 program works smile
Posted By: Matt Burke

Re: Requirements? - 12/20/13 09:44 PM

Hi everyone,

I think I can help with the LK201 as I have both the 8051 and 6805 variant PCBs here. I also have an EPROM programmer so I'll read the 8051 in at some point. However I've traced the wiring on the 6805 PCB and I pretty much know which pin goes where now. The keyboard matrix is the same for both variants. I've made a start on modifying dec_lk201.c and have got this at least partly working with the VT220. I've added the input ports for the keyboard matrix, the code to scan it, the code to drive the LEDs and some of the code for the SCI and SPI interfaces. I've tried joining it to the Rainbow but I'm having some difficulty working out how to (correctly) use device_serial_interface. Also the bytes being sent out via port 0x10 to the 8251 UART do not seem to be keyboard commands? Perhaps I did something wrong? I think between us we should be able to get this working.

I metioned the VT220, this is actually where I started. There are two variants of this: one with an 8051, two program ROMs and a character ROM and a later variant with an 8031 and a single program ROM. I have started implementing the earlier variant as that is the one for which documentation is available. It currenly passes about 20 of the (?) self tests, but the LK201 is going to be needed so I started looking at that.

I guess the next step will be to send some diffs to someone and hopefully they can help me with device_serial_interface and hooking this up to the rainbow to test it properly.

Matt
Posted By: R. Belmont

Re: Requirements? - 12/20/13 10:02 PM

Matt: that's awesome! PM me and we'll figure something out smile
Posted By: rfka01

Re: Requirements? - 12/20/13 10:57 PM

Great news, Matt ... I just got a nice VT320 off Ebay for 20 ...couldn't let it pass ... now things like the P112 board are working in style smile
Posted By: Lord Nightmare

Re: Requirements? - 12/22/13 12:28 AM

I have a vt320 here, getting the roms out to dump those looks to be a gigantic pain in the ass, they're in a metal cage which seems to be soldered to the pcb, underneath the tube.

I also have a C.Itoh CIT-220+ which looks like it might be using stolen vt220 or vt320 code, unclear. It uses some very odd chips for graphics control, though everything is standard JEDEC ROMs for actual character sets, main code, etc. I have it fully dumped, including the keyboard MCU. (and I have to thank Kevtris for desoldering all 125 keys from the keyboard in order to facilitate repairing it, which is now done. Someone had spilled coffee into it years before I got it and it wicked up into the key contact leaves of most of the keys, so pretty much nothing worked) The C.Itoh keyboard is far more repairable than the LK201 is (usually lk201s get scrapped when they die because the membrane goes bad) and uses real spring+leaf switches for the keys rather than a membrane like the LK201 does.

LN
Posted By: rfka01

Re: Requirements? - 12/22/13 09:38 AM

Hi LN,

looks like we have got the ROM ... it's 23-054E7 in this directory:

http://www.dunnington.u-net.com/public/DECROMs/

and the pcb pic at

http://www.vt100.net/dec/vt320/pcb

shows one ROM.

Robert
Posted By: Bavarese

Re: Requirements? - 02/19/14 06:09 PM

Rainbow.c: i now have a clue why MS-DOS 2.x crashes (and CP/M 1.1 boots).

One reason is that our interrupt handling looks incorrect. There is additional IRQ logic not reflected in our code.

Please see the attached image in my Dropbox:

https://dl.dropboxusercontent.com/u/37819653/SH_6_VECTOR_SELECT.jpg

The screenshots are taken from the Field Manual of the PC-100 B, and the vital clue came from RBCONVERT.ZIP (File: CONVERT-A-B).

Next thing is the wrong sector interleave (1:1) instead of the following (sector count from 0 to 9):
LOG. => PHYS 0, 2, 4, 6, 8, 1, 3, 5, 7, 9
PHYS. => LOG. 0, 5, 1, 6, 2, 7, 3, 8, 4, 9

This is valid for both CP/M and MS-DOS; only for tracks >= 2; counted from track 0.

Please advise what to do.
The current code base is increasingly difficult to understand.
Help is appreciated.

wink

Posted By: R. Belmont

Re: Requirements? - 02/19/14 06:20 PM

Incorrect interleave shouldn't matter; software requests a specific sector from the FDC and it will fetch that sector. It's only a problem if the sectors in the image file aren't in the order the parser thinks they are (for instance due to a format that doesn't preserve that information).

The interrupt vector thing is interesting; what other hardware differences are there between the 100A and 100B?
Posted By: Bavarese

Re: Requirements? [Rainbow 100-A vs. 100-B ...] - 02/19/14 08:07 PM

A comparison...

RAM ADDRESSING / SIZES
> fixed 64 K RAM on board (instead of 128 K on board of PC-100 B)

> a maximum of 832 K RAM -with RAM extension board - (instead of 896 K on 'B')

ROM
> ROM 04.03.11 (for PC-100-A) in 3 chips (type 2764)
FA000-FBFFF (E89)
FC000-FDFFF (E90)
FE000-FFFFF (E91)


> PC-100B / PC100B+ has ROM 05.03 in 2 chips (type 27128) at memory addresses:
F4000-F7FFF
FC000-FFFFF


ROM DIFFERENCES (derived from my latest ROM disassembly)

(*) PC-100-B only. Not present in original PC-100 specification from March 1983.
0x1a and beyond are marked as 'reserved' there.
Code:
$1f23 - (*) ROM_RomVersion       0x1a  /* DX,BP<-offset,seg of 8-byte buffer */
$1f66 - (*) ROM_ChangeVectorMap  0x1c  
$1fc2 - (*) ROM_RingBell         0x1e
$1fc8 - (*) ROM_GetSet7or8       0x20  /* AH<-function (1=get, 0=set);       */
                                       /* AL<-value (0=8, 1=7) (set only) :  */
                                       /*     value->AL (get only)           */

There is no documented way to emit bell sounds on the Rainbow 100-A (confirmed in Jeff Armstrong's blog). No hardware limitation of course: the beeper sits in the keyboard.

The 'A' model did not come with a hard disc, and there were no provisions in the old ROM to boot from HD directly.


LIMITS WITH OPTION BOARDS

GRAPHICS (when using uPD7220 Graphics option)
> limited graphics palette: 4 colors where with the B board you get 16.

80286 ACCELERATOR BOARD
> Suitable Solutions 286 accelerator board runs in either a 100B or a 100+, but not a 100A.

Note that i own neither a 100-A nor the fancier option boards. I am also more into software than hardware. Feel free to correct me. smile
Posted By: R. Belmont

Re: Requirements? [Rainbow 100-A vs. 100-B ...] - 02/23/14 02:23 AM

SVN #27909 has IRQ management (I have no idea what the priorities are when more than one is signaled at a time but that can be easily adjusted) and the keyboard 8251's DTR line is connected to bit 7 of the IRQ vectors.

Let me know if that helps smile
Posted By: rfka01

Re: Requirements? [Rainbow 100-A vs. 100-B ...] - 03/09/14 08:29 AM

https://dl.dropboxusercontent.com/u/83147066/Siemens%20PC-D%20Praxisbuch%20Anhang%202.pdf

Here is more technical info on the Siemens PC-D - it's in German, but if some kind soul wants to work on the driver, I'll translate what's necessary.

Robert
Posted By: Bavarese

Re: Requirements? [Rainbow 100-A vs. 100-B ...] - 03/11/14 03:14 PM

Here is a nice TXT that explains interrupt vector assignments, and more differences between the 'A' and 'B' models (and DOS 2.01 vs. 2.05).

I was asked about IRQ priorities. VBI has highest,
'Interrupt from Z80' has lowest priority (others are in between, in the order shown below for 40 thru 47 or A0 - A7
.

Subj: MS-DOS Interrupt Vector Assignment

Rainbow 100 MS-DOS Interrupt Vector Assignment (in hexdecimal)

Interrupt 0 - Divide by zero
Interrupt 1 - Single step
Interrupt 2 - NMI used for Memory Parity error or 8087 error
Interrupt 3 - Break point instruction
Interrupt 4 - Overflow

Interrupt 18 - Firmware functions

Interrupt 20 - DOS program terminate
Interrupt 21 - DOS function call
Interrupt 22 - DOS terminate address
Interrupt 23 - DOS Control-Break exit address
Interrupt 24 - DOS fatal error address
Interrupt 25 - DOS absolute disk read
Interrupt 26 - DOS absolute disk write
Interrupt 27 - DOS terminate & fix in storage
Interrupt 28 thru 3F - Reserved for DOS

; INT 40 thru 47 are used for hardware interrupt if:
; 1. use MS-DOS V2.01,
; 2. use RAINBOW 100 (not 100+).

Interrupt 40 - Vertical frequency refresh interrupt
Interrupt 41 - Not used
Interrupt 42 - Graphic controller interrupt
Interrupt 43 - DMA controller interrupt (from extended comm. board)
Interrupt 44 - Communication/Printer interrupt
Interrupt 45 - Hard disk or Extended communication interrupt
Interrupt 46 - Keyboard interrupt
Interrupt 47 - Interrupt from Z80

Interrupt 64 - timer (60 or 50 ticks/second)

; INT A0 thru A7 are used for hardware interrupt if:
; use MS-DOS V2.05 (or above) WITH RAINBOW 100+.

Interrupt A0 - Vertical frequency refresh interrupt
Interrupt A1 - Not used
Interrupt A2 - Graphic controller interrupt
Interrupt A3 - DMA controller interrupt (from extended comm. board)
Interrupt A4 - Communication/Printer interrupt
Interrupt A5 - Hard disk or Extended communication interrupt
Interrupt A6 - Keyboard interrupt
Interrupt A7 - Interrupt from Z80

Interrupt F0 - Alternate DOS interrupt 22 - Terminate address
Interrupt F1 - Alternate DOS interrupt 23 - Control-Break exit address
Interrupt F2 - Alternate DOS interrupt 24 - Fatal error address

3. alternate interrupt vectors for DOS INT 20-27

DOS INT 20 ------------> INT F8
DOS INT 21 ------------> INT F9
DOS INT 22 ------------> INT F0
DOS INT 23 ------------> INT F1
DOS INT 24 ------------> INT F2
DOS INT 25 ------------> INT FD
DOS INT 26 ------------> INT FE
DOS INT 27 ------------> INT FF

if you read it by interrupt vectors order:

INT F0 ---- DOS INT 22
INT F1 ---- DOS INT 23
INT F2 ---- DOS INT 24
INT F3 thru F7 reserved by DOS
INT F8 ---- DOS INT 20
INT F9 ---- DOS INT 21
INT FA ---- reserved by BIOS
INT FB ---- reserved by BIOS
INT FC ---- reserved by BIOS
INT FD ---- DOS INT 25
INT FE ---- DOS INT 26
INT FF ---- DOS INT 27

Source: RBTECDOC.ZIP (Latrobe and mirrors)

Posted By: R. Belmont

Re: Requirements? [Rainbow 100-A vs. 100-B ...] - 03/11/14 03:20 PM

Gotcha, the priority's easy enough to fix.

Is "RAINBOW 100 (not 100+)" 100A?
Posted By: rfka01

Re: Requirements? [Rainbow 100-A vs. 100-B ...] - 03/11/14 03:45 PM

The info on Wiki seems to be corroborated by this:

http://oldcomputers.net/dec-rainbow-100.html

First Rom, HD not supported = Rainbow 100A
Second Rom, HD supported but not factory installed = Rainbow 100B
Second Rom, HD supported and factory installed = Rainbow 100+

Robert
Posted By: Bavarese

Re: Requirements? [Rainbow 100-A vs. 100-B ...] - 03/11/14 03:46 PM

'100' = '100-A' (system module 70-19974-00, PSU H7842-A, 24 K ROM)
'100+' = '100-B' (system module 70-1994-02, PSU H7842-D, 32 K ROM)

Once upon a time there was a 'Winchester Upgrade Kit' for the '-A'. Could explain the '+' sign.

Question: are the alternate interrupts (above) implemented in our driver?


Posted By: R. Belmont

Re: Requirements? [Rainbow 100-A vs. 100-B ...] - 03/11/14 03:48 PM

Yes, bit 7 of the interrupt vector is controlled by the appropriate line on the keyboard 8251, as per the schematics.
Posted By: Bavarese

Arbitration logic to blame? - 05/20/14 09:15 AM

Some facts about the mysterious arbitration logic inside the Rainbow...

Quote: reliable floppy operation is not possible 'if both CPUs operate outside of shared memory'.

View from Z80:
- private RAM (2 K static RAM) can be accessed at any time without any wait states

- 62 K shared RAM considered 'busy' when an 8088 cycle or a refresh cycle is in progress
- an arbitration logic ensures that refresh has highest priority. Z80 has equal priority to 8088 except in cases where both access shared memory (Z80 wins).
- if shared RAM is 'busy' at the time of Z80 access, the Z80 will execute wait states until the RAM is free
- extra +1 wait cycle on machine one (M1) cycles when accessing shared memory. WAIT is also used When the RX50 board decides it needs additional time.

In any case, the Z80A is held in a wait state no longer than ~ 2 us.

References: Technical Manual 3.3.1 (page 72); 4-17 (page 115; fig.4-10) ; 4-22 (4.4.5.1) page 120.

In the light of the deadlocks observed - will it be necessary to emulate all this? sick

P.S.: the READ ID fix Curt did for Osborne had no (apparent) impact on 'rainbow.c' - so i'll submit my patch - minus the keyboard workaround - to version control and hope for the best.

Currently, 'READ_ID_BLOCK_TO_DMA' and 'READ_ID_BLOCK_TO_DMA_BYTE' fail on the Rainbow with CPM 2.x (CPM 1 and DOS 3 boot, other issues with DOS 2.x remain).
Posted By: smf

Re: Arbitration logic to blame? - 05/20/14 10:46 AM

Originally Posted By Bavarese
In the light of the deadlocks observed - will it be necessary to emulate all this? sick


It's nice to make buggy software fail on an emulator the same as it does on real hardware, but in this case I suspect the overhead far outweighs the benefit.

You will struggle to find any software that relies on the unreliable floppy operation, so how would you test it?
Posted By: R. Belmont

Re: Arbitration logic to blame? - 05/20/14 11:59 AM

smf is correct: by definition, if floppy operation on the hardware is correct and doesn't randomly fail all the time, then obviously the operating systems do not cause trouble with the arbitration. And therefore there is no need to emulate it in order to get them to boot and run.


ETA: There is one wrinkle, though.

Quote:
WAIT is also used When the RX50 board decides it needs additional time.


Some systems in MESS cannot currently be emulated because they wire the WDx7xx so that it halts the CPU when its busy, and then the firmware/software doesn't need to ever busy-wait for the controller. If the RX50 is actually wired that way, you might be in trouble, but the fact that multiple OSes do boot already suggests that that isn't the case. It would be useful to trace on the schematics exactly what causes the RX50 to assert WAIT though.
Posted By: Bavarese

Re: Requirements? - 05/23/14 10:28 AM

Guys, I am only trying to find out why the current implementation (even with newest floppy code ***) is so unreliable smile

Isn't it possible that the 'shared memory' arbitration we talked about synchronizes both CPUs - and we miss important details?

When i look at the signals passed at the J1 connector (left = computer; right = floppy) i can't find evidence that the Z80 is halted by the RX50 controller -

https://dl.dropboxusercontent.com/u/37819653/RX50_Controller_5415482.png

@R.Belmont: there is a 500 ms delay between MOTOR ON and DISK SELECT (middle part). How is that implemented best?

The following bugs remain in current SVN:

a. occasional deadlocks between Z80 and 8088 (near or at HLT instruction).
-> CPU communication / timing? Z80 core?

b. DOS 2.x and CPM 2.x booters fail (CP/M BDOS: 'Read error at track 2 sector 1').
-> The bootstrapper (1) loaded via READ SECTOR, the 2nd part begins with READ ID and fails
-> Think it is command 0xc0; see also my post here )

c. CP/M 1 -sometimes- prints segment addresses to the console
-> crashes during floppy operation...?

d. UCSD systems probe A,B,C then D - and lock up if not all 4 drives have images attached.
-> Drive detection!

crazy

(***) preliminary version (patch against 30456):
https://dl.dropboxusercontent.com/u/37819653/_Prelminiary_PATCH_for_SVN_30456.diff

https://dl.dropboxusercontent.com/u/37819653/_MISSING_FILES_for_SVN_30456.7z
Posted By: mizapf

Re: Arbitration logic to blame? - 05/24/14 04:06 PM

Originally Posted By R. Belmont

Some systems in MESS cannot currently be emulated because they wire the WDx7xx so that it halts the CPU when its busy, and then the firmware/software doesn't need to ever busy-wait for the controller. If the RX50 is actually wired that way, you might be in trouble, but the fact that multiple OSes do boot already suggests that that isn't the case. It would be useful to trace on the schematics exactly what causes the RX50 to assert WAIT though.


In essence, those scenarios were the reason why I introduced the feature to split read accesses in the address map (set the address bus, then read), for the sake of those systems that get suspended in the middle of a memory read. The TMS99xx emulations prove to work that way

Maybe this could be ported to other systems as needed; I'd be ready to help.
Posted By: shattered

Re: Arbitration logic to blame? - 05/27/14 05:50 AM

The CPU halt can be faked by resetting IP -- mc1502 and poisk1 work this way (but for some reason the former has to reset one insn back and the latter, two...)
Posted By: R. Belmont

Re: Arbitration logic to blame? - 05/27/14 10:53 AM

Right, but that doesn't appear to be how this system works, otherwise nothing would load at all from the floppy.
Posted By: Bavarese

Re: Requirements? - 05/27/14 06:44 PM

Thanks for all ideas & suggesstions so far!

@R.Belmont: different OS employ different bootstrapper strategies, don't they?
At least with CP/M 2, another loader kicks in on track 2 (and that's when the trouble starts...)


With the knowledge i have now, i see two following TODOs:

- eliminate the need to employ a gross hack to activate the keyboard grin

- wire the READY signal correctly (floppies aren't always READY on the Rainbow...)

- implement a connection between HLT and HLD (head load timing and head load). It isn't there now in 'wd_fdc'.
Besides, how can i properly RESTORE with the current code?

- make improvements on the RAM access logic because the 'bundle cards' (at least the COMM OPTION board; maybe also the WD based hard disc controller?) require DMA.

See the signals labeled with BDL for BUNDLE at extension port J4 - and in the schematics attached.

Possibly a hardware guru can tell what the undocumented B1-03 (E13) is capable of...?

https://dl.dropboxusercontent.com/u/37819653/ARBITRATOR.png

The Z80 gets WAIT - but i don't see how the (external) RX50 board - on connector J1 (see see link in previous posting) - could possibly affect it -

https://dl.dropboxusercontent.com/u/37819653/Z80.png



Posted By: Bavarese

Re: Requirements? - 06/04/14 07:09 PM

Code:
Possibly a hardware guru can tell what the undocumented B1-03 (E13) is capable of...?

https://dl.dropboxusercontent.com/u/37819653/ARBITRATOR.png


E13 (or E11 on 100-A) is labeled '256 x 8 arbitration ROM' and soldered directly to the motherboard.

The schematics from 100-A is a bit clearer on this:

https://dl.dropboxusercontent.com/u/37819653/PC100_A__E11_Arbitrator_-_256_x_8.png
(note the difference on pin 5 when compared to 100-B ).

Unfortunately, it is a small chip in a confined space.

Will we get away without it?


blush OMG...i am talking to myself
Posted By: R. Belmont

Re: Requirements? - 06/04/14 08:22 PM

You have a more immediate problem: the WDx7xx does *not* have a means for external hardware to trigger a RESTORE. I told you this before, you ignored me, and now your submission has been rejected.
Posted By: Bavarese

Re: Requirements? - 06/05/14 11:30 AM

If ignorance is defined as a 'lack of knowledge' (Webster's), i am guilty.

Annoying people who helped me - more often than expected - is not my intention.

You mentioned that the 8088 cannot issue FDC commands. The FDC and the Z80 can pass (read and write) data via a common 8 bit wide bus.

The patch tried to execute both RESTORE and RESET within the main driver. I understand this shortcut (and the modification of 'wd_fdc') is considered 'unfaithful' and therefore incorrect.

Are there other objections, or will a complete rewrite be in order (e.g. move FDC related registers out to a RX50 controller device that interacts with the Z80)...?
Posted By: Curt Coder

Re: Requirements? - 06/05/14 12:28 PM

The wd17xx issues a Restore command on reset, what is the problem there?

http://git.redump.net/mame/tree/src/emu/machine/wd_fdc.c

lines 145-147
Posted By: R. Belmont

Re: Requirements? - 06/05/14 01:49 PM

As you've noted, resetting the wdx7xx should have the same effect, but apparently the Rainbow only works if you do both.
Posted By: rfka01

Re: Requirements? - 06/30/14 04:51 PM

In the period just before the NCR DMV driver got the modernized floppy driver based on the NEC PD765, the driver showed the correct screen for "no floppy inserted, sitting here patiently"



It didn't boot, but it showed the correct screen. As I can no longer build the old revisions, I can't provide the revision, when this changed to a blank screen where nothing happens.

The recent change to the 765 code (r30943) provoked a change in the DMV behaviour: Now an error message that is related to the drive/disk configuration shows up.



It would be great if devs could look into this and maybe nudge the DMV along to boot.

Thanks
Robert
Posted By: Bavarese

Re: Requirements? - 07/03/14 07:46 PM

After lengthy debugging, the Rainbow now boots DOS 3.10 (with a proper NVRAM file that must match DIP / RAM Settings)...

Still, DOS 2.01, DOS 2.05, DOS 2.11, CP/M 2.x _and_ Concurrent CP/M fail with quite the same error!

Now i have a good log from an attempt to boot Concurrent CP/M - together with a commented source file from Digital Research (-> right hand side -> WD1797).

It shows why the seek to track 00 happens - instead of a seek (or read) @ track 2 - as expected.

https://dl.dropboxusercontent.com/u/37819653/SEEK_TO_TRACK_0_in_case_of_error.jpg

pattern T0 -> T1 -> T0 repeats with all 2.x disks mentioned.

As always, some hints would be nice. I am a bit out of ideas...
Posted By: rfka01

Re: Requirements? - 07/03/14 08:50 PM

@Sandro Ronco

Thank you very much for your work on the NCR DMV driver ... it's amazing to see the machine come to life.

As always the following thoughts are just meant as ideas, not as impatient nagging or criticism.

Althought the DMV now boots CP/M, the error message with no disk inserted as shown in the before last post persists. The message should simply read "Disk A: not ready (CR)"

The DMV relies heavily on its slots and modules.
Slot 1 can take a 64K, 192K or 448K memory module.
Slot 7 can take a CPU module (8086 or 68008) or the diagnostics module. There is a slot 7a on the rear side of some mainboards that can take the internal 8086 module.
Slots 2-6 can take the various expansion modules (Centronics, Serial, RTC, Mouse, Harddisk). On some machines there is a slot 3a on the rear side that accepts the internal harddisk adapter.

A few pages back I posted these files that could come in handy now the DMV is booting.

Originally Posted By rfka01
Sometimes small wonders happen ... I was given the DMV diagnostic module by a guy who used to work for NCR ... he has already ditched the module case, but miraculously kept the PCB.

This archive contains the dumps of the two EPROMS.

DMV Diagnostics module

[...]

NCR DMV pictures

[...]

I've prepared two files that could, once they're filled with actual code, reside in emu/bus/dmv ... one is dmvbus.c, the other is dmvdiag.c, both contained in the above archive. At the moment they only contain ASCII graphics of the bus connector resp. the PCB layout of the diagnostics module.

Also included is the PDF about the diagnostics module from the documentation and a picture of the PCB.



Again, Sandro, thanks a lot for your work.

Robert
Posted By: crazyc

Re: Requirements? - 07/03/14 09:00 PM

Originally Posted By rfka01

Althought the DMV now boots CP/M, the error message with no disk inserted as shown in the before last post persists. The message should simply read "Disk A: not ready (CR)"


That error just means the drive isn't ready so I don't know why it wouldn't just display the "not ready" error. Possibly the ready line isn't supposed connected to the controller.
Posted By: rfka01

Re: Requirements? - 07/03/14 09:12 PM

The system technical manual "Hardware" has schematics starting from page A143.

https://dl.dropboxusercontent.com/u/55419307/NCR%20DMV%20System%20Technical%20Manuals.zip

Robert
Posted By: rfka01

Re: Requirements? - 07/10/14 02:39 PM

I was looking through the MESS drivers to find one that uses the same graphics chip (the NEC PD7220) as the NCR DMV and already has the UPD7220_DISPLAY_PIXELS_MEMBER entry populated.

The Epson QX10 driver fits that category, and it seems to use a similar model to differentiate between its monochrome and colour graphics adapter (1 colour plane vs. 3 colour planes, on the DMV 32KB vs. 96KB of graphics memory).

Unfortunately the QX10 driver still seems to have some issues as the one disk image that boots into a graphics mode automatically (the keyboard's dead too) has the graphics sort of backwards.



The disk image in question is mathprof from Don Maslin's disk archive and can be found here http://fjkraan.home.xs4all.nl/comp/qx10/disklibrary.html

The missing graphics mode prevents a number of software items from running on the DMV driver, such as the DMV graphics demo that can be seen here http://www.youtube.com/watch?v=7Q49hD1gci8

The program should be demo5.com that can be found here https://dl.dropboxusercontent.com/u/55419307/80NCRGRF.TD0

Robert
Posted By: R. Belmont

Re: Requirements? - 07/10/14 02:47 PM

The individual character cells are flipped; that should be fairly easy to fix.
Posted By: rfka01

Re: Requirements? - 07/10/14 02:52 PM

The 7220 has a text only and a "mixed mode" for graphics and text ... I think that's the one used here. The mathprof demo start screen is quite long with jumbled graphics, so it's a good test point smile
Posted By: rfka01

Re: Requirements? - 07/11/14 09:05 PM

I've updated the "NCR Diagnostics Module" archive from a few posts up with more info on the Bus(es).

Slot 1 (memory modules) has a different pinout, but the same physical connector as the expansion module slots.
Slots 7 and 7a (CPU and Diagnostics modules) carry additional signals to slots 2-6

Robert
Posted By: Bavarese

Re: Requirements? - 07/17/14 03:11 PM

I have an idea why the 8251 does not pass the BIOS check on a Rainbow-100

The startup code uses an internal loopback to check the communication, printer and keyboard ports (all serial) for framing errors.

Bit 4 and bit 5 in 8088 register 0A (diagnostic write) are used in the process.

This is done in a way that the output of one port is connected to another when bit 5 is set.

We neither have COMM, PRINTER, nor loopback connected to anything. So the Rainbow startup code literally falls apart (as tests are incremental; COM -> PRN -> KBD -> FLOPPY ...)

Bit 4 uses a similar concept to validate the video and floppy controller signals with the help of a printer port.

Info pieces are from chapter 2.1.7.2 and 2.1.7.3 of AA-V523A-TV (PDF March 83).

Code:
WRITE8_MEMBER(rainbow_state::diagnostic_w) // 8088 (port 0A WRITTEN). Fig.4-28 + table 4-15
...
	// * BIT 4: DIAG LOOPBACK (0 at power-up; 1 directs RX50 and DC12 output to printer port)

	/* 2.1.7.3 DIAGNOSTIC LOOPBACK Maintenance Bit - The DIAGNOSTIC LOOPBACK bit is a
	    maintenance bit that is cleared on power - up.This bit, when set to 1,
		allows the floppy data separator and the serial video output to be tested
		through the use of the printer port. The following table shows how signals are routed.
		
		DIAGNOSTIC LOOPBACK = 0		DIAGNOSTIC LOOPBACK = 1		SIGNAL INPUT
		SIGNAL SOURCE				SIGNAL SOURCE		TO
		FROM					FROM				
		PRT RDATA(J2)				VIDEO OUT		PRT RXD(7201)
		PRT RXTXC				500 KHZ			PRT RXTXC(7201)	
		MASTER CLK				250 KHZ			VIDEO CLK(DCO11)
		FLOPPY RAW DATA				PRT TXD(7201)		FLOPPY DATA SEPARATOR

		During Diagnostic Loopback, the - TEST input of the 8088 is connected to the
		interrupt output of the MPSC.Thus, using the 8088's WAIT instruction in a
		polled I / O loop, the diagnostic firmware will be able to keep up with the
		500 Kb data rate on the MPSC.
    */
	if (data & 16)
	{
		printf("\nWARNING: UNEMULATED DIAG LOOPBACK (directs RX50 and DC12 output to printer port) ****");
	}

	if (data & 32)
	{
		/* BIT 5: PORT LOOPBACK (1 enables loopback for COMM, PRINTER, KEYBOARD ports)
		2.1.7.2. of AA-V523A-TV (PDF Mar83) says how the signals are routed:
		port_loopback_0  |  port_loopback_1   SIGNAL INPUT TO
		COMM RCV DATA.......COMM TXD..........COMM_RXD
		PRT  RCV DATA.......KBD TXD...........PRT RDATA
		KBD  RCV DATA.......PRT TXD...........KBD RXD
		*/
		printf("\nWARNING: UNEMULATED PORT LOOPBACK (COMM, PRINTER, KEYBOARD ports) ****");
	}


I could use some help here ;-)

-----
Newest disassemblies of low and high ROM

23-022e5-00.bin
23-020e5-00.bin

https://dl.dropboxusercontent.com/u/37819653/2014_07_Rainbow_ROM_DISASSEMBLED.7z
Posted By: R. Belmont

Re: Requirements? - 07/17/14 03:15 PM

Ahh, that's interesting, and it could definitely help understand why we sync the bitstream correctly and then lose it later. I'll try and set that up later today.
Posted By: R. Belmont

Re: Requirements? - 07/21/14 01:14 AM

Didn't get this going as quickly as I thought, I forgot we didn't have comm or printer ports at all yet smile The disassemblies are definitely helpful though!
Posted By: R. Belmont

Re: Requirements? - 07/22/14 01:43 AM

I've added COM and LPT ports and set them up to loopback properly (COM->COM, LPT->KBD, KBD->LPT). It's not working yet, so I'm diving into the ROM code to try and figure out what's actually going on.

The disassemblies unfortunately almost completely miss most of the failing diagnostic code (e.g. the interrupts test at ~F4C30) so I'm having to disassemble manually.
Posted By: Bavarese

Re: Requirements? - 07/23/14 10:44 AM

Yeah, the disassemblies are not perfect. Interrupt handling is especially fuzzy (though F4C30 _should_ be somehow covered).

Had hopes (in the past) that an Intel (or IDA) expert steps in and improves it.

With IDA 5 Freeware you'd be able to improve the source AND follow the execution flow more easily (-> graph feature, jump back and forth etc.)

Unfortunately, i am away this week and can't provide the most up-to-date IDB file necessary.
Posted By: R. Belmont

Re: Requirements? - 07/23/14 11:44 AM

Not a problem. The 7201 printer port is now receiving the correct test byte sent from the keyboard 8251 but the test is showing as failed anyway so I'm trying to figure out why smile
Posted By: R. Belmont

Re: Requirements? - 07/24/14 02:42 AM

We're now passing more of the tests, but MESS's existing 7201/z80dart emulation isn't lowering the interrupt line when it should, which means we get SYSTEM ERROR 2 (unsolicited interrupt). Working on it.

ETA: email sent to Curt, I don't understand what the 7201 is meant to be doing exactly smile
Posted By: crazyc

Re: Requirements? - 07/24/14 04:09 AM

I bet that your problem is that you aren't reading the m1_r line to ack the interrupt. I think that it is a z80sio/dart thing that doesn't exist on the i8274/upd7201 but is currently required by the shared emulation.
Posted By: R. Belmont

Re: Requirements? - 07/24/14 04:16 AM

The 8088 issues the 0x38 RETURN_FROM_INT command to the 7201 at the end of the ISR, but that causes z80_irq_reti() to hit the "Failed to find an interrupt to clear IE0 on" message and so the interrupt isn't cleared.

As far as I know, the alternate clear is only for the 8274, not the uPD7201, but I could be wrong.
Posted By: Bavarese

Re: Requirements? - 07/24/14 02:10 PM

The old link has been updated to include 2 binary IDB files (suitable for IDA 5).

I'd be interested which parts of the HTML output were flaky
shocked

A co-worker once advised me not to submit binary files to version control. So how can we start a collaborative effort?
Posted By: R. Belmont

Re: Requirements? - 07/24/14 02:51 PM

I'd like to think we're actually nearing the end of needing to read disassemblies for this system, but we'll see :-)
Posted By: Bavarese

Re: Requirements? - 07/31/14 07:22 PM

To give something back to the community, i have delved into 'cpmtools' (LIBDISK). The original Win32 distribution was incredibly hard to use.

List, verify, empty, extract (or populate) CP/M images for VT180 and Rainbow-100 (*.img / *.td0).

https://dl.dropboxusercontent.com/u/37819653/CPMTOOLS_FOR_VT180_and_Rainbow100.7z

Comes with updated DISKDEFS. Win-32. GPL.

----------------
@R.Belmont: the "Design Maturity Test" disk contains 2 programs that could be interesting (disk boots, as does DIAG) -

CDVT CMD : PC100-B COMM DIAGNOSTIC REV 1.0 June 17 1983
XDVT CMD : Communications Diagnostic Rev 3.0 June 10 1983

Thank you very much for your patience and commitment.
Posted By: Bavarese

Re: Requirements? - 08/01/14 09:45 AM

Now that CP/M is handled (-> previous page), here a suitable tool for DOS
INTERLEAVE / DE-INTERLEAVE RAINBOW-100 DISKS

A VB.NET 2010 Express Project (console application). VB source provided. Replacement for PUTR, which is not up to the task (as it damages tracks 0 and 1).

Works only with bootable DEC Rainbow _DOS_ images (*.img; 80 x 10 sectors; 409.600 Bytes).

https://dl.dropboxusercontent.com/u/37819653/skew_unskew.7z

FURTHER REFERENCE: 'A Skewed View of Disk Geometry'
http://jeff.rainbow-100.com/?p=43

Recommended to OPEN and EDIT * unskewed * disks
http://hp.vector.co.jp/authors/VA013937/editdisk/index_e.html

Code:
 Profile selection: (Manual FD)

 [Search] -> [Search] -> "IPL Device found" ( FAT12 and all other values are populated now, thanks to the patched BPB )

 [OK] and you are done.

A second invocation of the skew tool automagically skews the disk again (and removes the BPB) so everything is back to normal.

The reason why this tool handles only DOS is that there are many 409.600 byte images floating around (P/OS, VT180, DEC Pro) and i didn't want to break them.
Posted By: rfka01

Re: Requirements? - 09/18/14 09:52 AM

Darkstar mentioned in the shoutbox that there are new Rainbow schematics available on bitservers ... let's preserve that link before it scrolls off:

http://tinyurl.com/mmuwtxj
Posted By: Bavarese

Re: Requirements (Rainbow-100 HD emulation WD2010) - 03/05/15 01:54 PM

Hi,

i have seen there is some progress on the WD 2010 (= WD 1010) controller.

The NGEN skeleton invokes "harddriv.h" and "wd2010.h" since recently.

http://git.redump.net/mame/commit/?id=29faa4ce8395ec222914c818b4e22117c8d196e6

Is this controller usable?

As soon as interrupts come into play, i am stuck. An IRQ should occur whenever the sector buffer is ready. No DMA transfers are used.

Most drivers assume an ISA or XT architecture (-> P1_HDC; WD_XT), so there is no real reference to cling to.

Long story short: i can't make head or tail of the MCFG or _CB statements necessary.

Attached is an unofficial version of the Rainbow-100 driver, complete with LK201 keyboard workaround and two digit (floppy) track display for anyone interested.

STATUS: few booters start (DOS 3, UCSD Pascal and DIAG DISKs), hard disk sector transfers do not complete - see above - and floppy writes are flaky (Z80 timing or Z80 <-> 8088 arbitration).

Improvements are welcome ;-)


https://dl.dropboxusercontent.com/u/37819653/BANNISTER/_March_2015_.7z

--- REFERENCES

* EK-RB100-TM_001_Rainbow_Technical_Manual_Addendum_for_PC100-A_PC100-B_and_Rainbow_100+_Dec84.pdf

* RD51 Controller Circuit Schematics / part number: CS-54160 19-0-1 (not online ?)

* Command line used for ST412 (= DEC 'RD51'; hunk size unverified):

chdman createhd -o RD51xx.chd -chs 306,4,16 -ss 512 -hs 2048

https://dl.dropboxusercontent.com/u/37819653/BANNISTER/HARD_DISC_INTERFACE_1.jpg

https://dl.dropboxusercontent.com/u/37819653/BANNISTER/HARD_DISC_INTERFACE_2_TEXT.jpg

https://dl.dropboxusercontent.com/u/37819653/BANNISTER/WD1010_HDC.jpg

Posted By: Bavarese

Re: Requirements? - 04/01/15 09:32 PM

Some progress... Ah yes, and the WD2010 is not exactly register compatible to the WD1010 (2047 vs. 1024 cylinder limit etc.)





cool

A lot of guesswork was necessary, as the controller schematics haven't turned up -


Posted By: rfka01

Re: Requirements? - 04/04/15 11:15 PM

Saving this before it scrolls off:

Bavarese asked in the shoutbox:

Bavarese: Is a "low level format" necessary when working with new CHD (hard disk) images? Classic MFM hard drive with CHS addressing...
Posted By: R. Belmont

Re: Requirements? - 04/05/15 12:35 AM

You shouldn't ever have to do a low-level format in the emulation, unless we go to a much lower-level representation of the HDDs.
Posted By: Lord Nightmare

Re: Requirements? - 05/01/15 05:17 PM

Blast from the past (2012): rainbow-100.com is down and I cannot find the archive of the two rainbow roms from http://web.archive.org/web/20130525015112/http://rainbow-100.com/archives/163/

Were these the 23-020e5 and 23-022e5 arbee had mentioned?
Also which character rom was verified? The 'normal' 23-018e2 one? We are STILL looking for the 23-094e2 'alternate character generator' rom which provides characters 128-255. It turns out to be much rarer than I thought.

Originally Posted By Bavarese
OK. The checksums of the 3 EPROMs i dumped today are exact duplicates of those available as a download on "Drive W" (rainbow-100.com). The character rom is also identical. Sigh. :-)

@rfka : would you lend a fellow countryman your 100-B motherboard? Do you have a DEC compatible monitor?

I'd really like to peek on the data of the winchester drive (Seagate ST-412 MFM and therefore incompatible to modern computer hardware)...

Spent the evening trying to repair the broken MB (see post above), but gave up.

Originally Posted By R. Belmont
We have a "German-French-English" ROM right now, part numbers 23-022e5-00 and 23-020e5-00. If yours is another part, that would be interesting to get dumped at some point.

Lord_Nightmare just dumped the controller ROM from an LK201 which will help further the emulation smile
Posted By: rfka01

Re: Requirements? - 05/01/15 05:48 PM

Unfortunately I haven't saved that file either, but I've contacted the owner of the Drive W site ... he's been active on Twitter only a few days ago, so there's a chance.
As for the other files, one of my machines resides now with Bavarese ... I'd need to open the other two to check for chip labels and probably re-read the chips to identify which dump belongs to which machine frown

Robert
Posted By: Bavarese

Re: Requirements? - 05/02/15 11:32 AM

Hi. The 2 EPROMs in my first Rainbow 100 B had hashes identical to the ´rainbow.c´ driver (below). The character generator (unerasable) was also identical. All 3 hashes matched the ZIP on Drive W.

I kept the original archive from Jeff for reference, if someone is interested smile

The Rainbow 100 A dumps would make a nice addition. One proud owner even posted on the DEC section of www.vintage-computer.com and sent me a photo (!) of the 3 ROM chips, but did not respond to later enquiries. Guess he sold his stuff.

None of the 100 A EPROMs (3 x 2732) had serial numbers printed on them. Will re-check the OTP / PROM on the B when time permits.

Code:
// ROM definition for 100-B (system module 70-19974-02, PSU H7842-D)
// - 32 K ROM (version 5.03)
ROM_START(rainbow)
ROM_REGION(0x100000, "maincpu", 0)
ROM_LOAD("23-022e5-00.bin", 0xf0000, 0x4000, CRC(9d1332b4) SHA1(736306d2a36bd44f95a39b36ebbab211cc8fea6e))
ROM_RELOAD(0xf4000, 0x4000)
ROM_LOAD("23-020e5-00.bin", 0xf8000, 0x4000, CRC(8638712f) SHA1(8269b0d95dc6efbe67d500dac3999df4838625d8)) // German, French, English
ROM_RELOAD(0xfc000, 0x4000)
ROM_REGION(0x1000, "chargen", 0)
ROM_LOAD("chargen.bin", 0x0000, 0x1000, CRC(1685e452) SHA1(bc299ff1cb74afcededf1a7beb9001188fdcf02f))
ROM_END
Posted By: Lord Nightmare

Re: Requirements? - 05/03/15 02:17 AM

What is the 23-xxxe3 number for the rainbow chargen?

LN
Posted By: rfka01

Re: Requirements? - 05/03/15 07:43 AM

If it's the one on the top right in this picture of a Rainbow 100B mainboard

https://dl.dropboxusercontent.com/u/55419307/DEC%20Rainbow%20100/Rainbow%20Mainboard%201.jpg

it's 23-U37E3
Posted By: Lord Nightmare

Re: Requirements? - 05/03/15 09:29 AM

23-037E3, you mean. The top of the 0 is scraped off.

Is that rom dumped from a 100A or 100B?

Does the rom have any different marking on 100A vs 100B?

There is also an undumped soldered down 82s135 prom, 23-090B1 near the left edge of that image, around the centerline.
At some point we should dump it, but probably not immediately necessary unless it holds something really important. Do we have schematics of this board?

LN
Posted By: Lord Nightmare

Re: Requirements? - 05/03/15 09:42 AM

Interesting! the 23-037E3 font (assuming that's what 'chargen.bin' is), if you discount the 6 unused rows of pixels, the first half matches the 23-018E2 vt100 font. Whats more interesting is the second half, which may very well match the missing, undumped 23-094e2 'alternate character generator' rom from the vt100!

It has the section, paragraph, and foreign language characters I'd expect from the VT100-WK 'word processing' version.

LN
Posted By: Bavarese

Re: Requirements? - 05/03/15 11:14 AM

We might need 23-090B1 for a more faithful emulation, just like the PLA in a C-64.

I * guess * the E13 / 23-090B1 is a 256 x 8 lookup table; Needed for -external- DMA access to lower memory (shared between Z80 and 8088).

Even more important: the arbitration chip also decides which of the two CPUs (Z80 or 8088) has access to contended, shared memory (< 64 K).

We observe strange floppy errors on writes (even with newest wd_fdc code). One explanation is that the arbitration slows down RAM accesses and floppy routines currently run too fast. Just a theory... WAIT is also wired on the Z80, but i dont ´get´ the logic behind it.

E13 on Rainbow-100 B
https://dl.dropboxusercontent.com/u/37819653/ARBITRATOR.png

E11 on Rainbow-100 A
https://dl.dropboxusercontent.com/u/37819653/PC100_A__E11_Arbitrator_-_256_x_8.png

Full schematics:
MP01722_PC100-B_Rainbow_Schematic_Jul84.pdf

E13 inputs (A = address lines)
Code:
+SH5 RF SH REQ H   -> Pin 19 (A7) shared memory request / refresh ?
+     1K -> +5 V   -> Pin 18 (A6) < UNUSED >
+SH 2 BDL ACK (L)  -> Pin 17 (A5) BUNDLE OPTION: IRQ acknowledged (*)
+SH 2 NONSHRCYC H  -> Pin 5 (A4) unshared memory cycle is in progress
+SH 2 PRECHARGE H  -> Pin 4 (A3) 
+SH 2 SHMUX 88 ENB -> Pin 3 (A2) shared memory
+SH2 DO REFRESH H  -> Pin 2 (A1) indicates that extended memory must be refreshed -> on J6 as (L)
+SH10 BDL REQ (L)  -> Pin 1 (A0) BUNDLE OPTION wishes to use shared memory  (*)


(*) BDL ACK + BDL REQ from external J4 connector

Additional header files required for the keyboard workaround (to test drive the Rainbow):
https://dl.dropboxusercontent.com/u/37819653/BANNISTER/RAINBOW-100_KEYBOARD_WORKAROUND.7z
Posted By: Lord Nightmare

Re: Requirements? - 05/03/15 04:18 PM

It sounds like we probably do need that prom dumped then.

Do you have any means to cleanly desolder it so it can be soldered back with no board damage?

Do you have a hakko fr300 (or its predecessor the 808) desoldering tool, and some 60/40 solder (and a temp controlled soldering iron) to wet/re-wet the pins with while de-soldering? Some paste flux may or may not help as well.

EDIT: Also what is it with DEC always assuming every prom is open collector and having a 5v pullup resistor array outside of them? I noticed this while trolling schematics for the past week. (They seem to have mostly stopped the pullups around 1983, dectalk era). Was this just DEC being anal about availability of replacement parts so they could use either an Open Collector or a Tristate PROM when replacing one during field service?

LN
Posted By: Lord Nightmare

Re: Requirements? - 05/03/15 06:28 PM

From the picure at https://dl.dropboxusercontent.com/u/55419307/DEC%20Rainbow%20100/Rainbow%20Mainboard%201.jpg
Is that motherboard a DEC Rainbow 100A or 100B?

Does the character generator rom have any different marking on 100A vs 100B?
Do you know what the 23-xxxEx markings are for the main cpu roms for both 100A and 100B?

Is the chargen.bin in the driver dumped from the 23-037E3 chip or another chip?

LN
Posted By: Bavarese

Re: Requirements? - 05/06/15 09:41 AM

Originally Posted By Lord Nightmare
From the picure at https://dl.dropboxusercontent.com/u/55419307/DEC%20Rainbow%20100/Rainbow%20Mainboard%201.jpg
Is that motherboard a DEC Rainbow 100A or 100B?


100B. 3 EPROMs (2 x 16 K; 1 x 4K).

100A has four EPROMs (E89 + E90 + E91 = 8K; 1 x 4K)
On a 100 A board there should be 3 x 2764 and one 2732 ROM...
(E91) 8 K - type 2764 (28 pins)
(E90) 8 K - type 2764 (28 pins)
(E89) 8 K - type 2764 (28 pins)

(E9 4K - type 2732 (24 pins)

Originally Posted By Lord Nightmare

Does the character generator rom have any different marking on 100A vs 100B?


This screenshot from a 100-A is all i got (yes, it lacks the char ROM)! And the 092E4 number (on the right) somehow dosn't fit.

https://dl.dropboxusercontent.com/u/37819653/BANNISTER/3_x_2764_-_DECRainbow-A-ROMS_Closeup.jpg

Originally Posted By Lord Nightmare

Do you know what the 23-xxxEx markings are for the main cpu roms for both 100A and 100B?


23-176e4-00= ROM (FA000-FBFFF) (E89) 8 K
23-177e4-00 = ROM (FC000-FDFFF) (E90) 8 K
70-20274-15 = SOCKETED LANGUAGE ROM (FE000-FFFFF) (E91) (USA *)
23-020e3-00 [E98] 2732 (4 K) EPROM * PART NUMBER 12-15006-06


(*) for more complete info, please have a look into the updated driver source (below).

100 -B info verified personally with Rainbow-100 revision "B" (FCC ID : A0994Q - PC100 - B).

100 -A info is from DEC manuals (see end of post).

Code:
// 'Rainbow 100-A' (system module 70-19974-00, PSU H7842-A)
// - first generation hardware (introduced May '82) with ROM 04.03.11
// - inability to boot from hard disc (mind the inadequate PSU)

// AVAILABLE RAM: 64 K on board (versus 128 K on model 'B'). 

// Two compatible memory expansions were sold by DEC:
// (PCIXX-AA) : 64 K (usable on either Rainbow 100-A or 100-B *)
// (PCIXX-AB) : 192 K ( " *) 
// Totals to 256 K on a 100-A, while the RAM limit appears to be 832 K.

// * INVESTIGATE: DEC changed the way RAM expansion cards are addressed 
//                and recognized on the Rainbow 100 B (J6 / BIOS / NMI...?)

// KNOWN DIFFERENCES TO 100-B:
// - cannot control bit 7 of IRQ vector (prevents DOS > 2.01 from booting on unmodified hardware)
// - 4 color palette with graphics option (instead of 16 colors on later models)
// - smaller ROMs (3 x 2764) with fewer routines (no documented way to beep...)
ROM_START(rainbow100a)
ROM_REGION(0x100000, "maincpu", 0)

ROM_LOAD("23-176e4-00.bin", 0xFA000, 0x2000, NO_DUMP) // ROM (FA000-FBFFF) (E89) 8 K
ROM_LOAD("23-177e4-00.bin", 0xFC000, 0x2000, NO_DUMP) // ROM (FC000-FDFFF) (E90) 8 K

// SOCKETED LANGUAGE ROM (E91) with 1 single localization per ROM -
ROM_LOAD("70-20274-15", 0xFE000, 0x2000, NO_DUMP)  // ROM (FE000-FFFFF) (E91) 8 K - USA 
// ROM_LOAD("bg-r873a-bv", 0xFE000, 0x2000, NO_DUMP)  // ROM (FE000-FFFFF) (E91) 8 K - Canadian (French)
// ROM_LOAD("bg-r876a-bv", 0xFE000, 0x2000, NO_DUMP)  // ROM (FE000-FFFFF) (E91) 8 K - British (UK)
// ROM_LOAD("bg-r878a-bv", 0xFE000, 0x2000, NO_DUMP)  // ROM (FE000-FFFFF) (E91) 8 K - German / Austrian 
// ROM_LOAD("bg-r874a-bv", 0xFE000, 0x2000, NO_DUMP)  // ROM (FE000-FFFFF) (E91) 8 K - Italian
// ROM_LOAD("bg-r377a-bv", 0xFE000, 0x2000, NO_DUMP)  // ROM (FE000-FFFFF) (E91) 8 K - Spanish
// (...)
// Appendix A / EK-RB100 Rainbow Technical Manual Addendum for 100A and 100B (Dec.84) lists all 15.
// See also MP-01491-00 - PC100A FIELD MAINTENANCE SET.

ROM_REGION(0x1000, "chargen", 0) // [E98] 2732 (4 K) EPROM * PART NUMBER 12-15006-06 * 23020E3-00
ROM_LOAD("23-020e3-00.bin", 0x0000, 0x1000, CRC(1685e452) SHA1(bc299ff1cb74afcededf1a7beb9001188fdcf02f))
ROM_END

//-------------------------------------------------------------
// ROM definition for 100-B (system module 70-19974-02, PSU H7842-D)
// Built until ~ May 1986 (from MP-01491-00)
// - 32 K ROM (version 5.03)
// - 128 K base and 896 K max. mem.
ROM_START(rainbow)
ROM_REGION(0x100000, "maincpu", 0)

// Note that the 'Field Maintenance Print Set 1984' also lists alternate revision 'A1' with 
//              23-063e3-00 (for chargen) and '23074e5-00' / '23073e5-00' for E5-01 / E5-02.

// Part numbers 22E5, 20E5 and 37E3 verified to match revision "B" (FCC ID : A0994Q - PC100 - B).

// BOOT ROM:
ROM_LOAD("23-022e5-00.bin", 0xf0000, 0x4000, CRC(9d1332b4) SHA1(736306d2a36bd44f95a39b36ebbab211cc8fea6e)) 
ROM_RELOAD(0xf4000, 0x4000)

// LANGUAGE ROM:
ROM_LOAD("23-020e5-00.bin", 0xf8000, 0x4000, CRC(8638712f) SHA1(8269b0d95dc6efbe67d500dac3999df4838625d8)) // German, French, English
//ROM_LOAD( "23-015e5-00.bin", 0xf8000, 0x4000, NO_DUMP) // Dutch, French, English
//ROM_LOAD( "23-016e5-00.bin", 0xf8000, 0x4000, NO_DUMP) // Finish, Swedish, English
//ROM_LOAD( "23-017e5-00.bin", 0xf8000, 0x4000, NO_DUMP) // Danish, Norwegian, English 
//ROM_LOAD( "23-018e5-00.bin", 0xf8000, 0x4000, NO_DUMP) // Spanish, Italian, English 
ROM_RELOAD(0xfc000, 0x4000)

// CHARACTER GENERATOR (E3-03)
ROM_REGION(0x1000, "chargen", 0) 
ROM_LOAD("23-037e3.bin", 0x0000, 0x1000, CRC(1685e452) SHA1(bc299ff1cb74afcededf1a7beb9001188fdcf02f))
ROM_END


Originally Posted By Lord Nightmare

Is the chargen.bin in the driver dumped from the 23-037E3 chip or another chip?


037E3, to the best of my knowledge.

The three dumps from my 100-B were identical to Jeff's archive on former 'Drive W'.

On another note, RFKA also got Rainbow-190 dumps (without char ROM), plus an archive from the owner of the TurboW (80286) expansion (Suitable Solutions; came with a slightly hacked 5.03 'B' ROM).

--------
Sources: "Appendix A / EK-RB100 Rainbow Technical Manual Addendum for 100A and 100B (Dec.84)"
See also MP-01491-00 - PC100A Field Maintenance Set
+ MP01722_PC100-B_Rainbow_Schematic_Jul84 (for rev."B")
Posted By: rfka01

Re: Requirements? - 05/06/15 11:25 AM

The owner of the TurboW and the "Drive W" website are one and the same person. He promised to look into getting "Drive W" up again soon, and wrote on the subject of the TurboW and the ClikClok:

"I haven't been able to find the original pictures of the Turbow-286 board yet, so I can't determine the chip details,
although it a realtively "common" chip used to interface 286 CPUs to 8088 systems (by my understanding). I doubt I'll be pulling out the motherboard of the Turbow any time soon, though. The Turbow-286 does not have a real-time clock on board. You'd need the separate ClikClok chip, which was just a Dallas Semiconductor clock chip and battery wedged in between the high ROM on the Rainbow and the motherboard (I don't know the wiring details or the chip used - Suitable Solutions painted over the chip labels to dissuade copycats)."
Posted By: Lord Nightmare

Re: Requirements? - 05/06/15 10:41 PM

70-20274-15 - this is a DEC part number for ordering the Language rom; based on the 100A MB picture, the actual part number written on the rom is

LM8402
092E4
this translates to:
23-092E4, burned on 1984 week 2 (what exactly LM means I'm not sure, guessing maybe 'local manufacture' i.e. burned from a .hex file to a rom in one of the many DEC 'branch' service centers?)

LN
Posted By: Lord Nightmare

Re: Requirements? - 05/06/15 11:17 PM

Here's my work of the past 2 weeks or so, a massive list, based on Pete Turnbull's dunnington.info/public/ lists of DEC ROMs and PROMs with a huge amount of new stuff added at the bottom:
https://dl.dropboxusercontent.com/u/79094972/DECROMs.xlsx

Let me know if there's anything you have dumps of, have on hardware, or know of from MP sheets, screenshots, FCOs (field change orders) or Dec-o-gram stuff which isn't on that list, so I can add it!
Also let me know if there are any errors.

LN
Posted By: Bavarese

Re: Requirements? - 05/07/15 04:24 PM

Great work!

MMI6308 PROM (in line 209) should be E11 on a Rainbow 100-A and E13 on 100-B (from schematics).
Posted By: Lord Nightmare

Re: Requirements? - 05/07/15 05:59 PM

Fixed, Thanks!

LN
Posted By: Bavarese

Re: Requirements? - 05/09/15 10:14 AM

Finally some progress on the Rainbow driver:

First, the Z80 still wrote to reserved address space (...with GIT code).
Caused 8088 crashes - and Z80 test failures! Fall through wasn't right - see correction below...

Code:
WRITE8_MEMBER(rainbow_state::share_z80_w)
{
	if (m_zflip)
	{
		if (offset < 0x8000)
		{
			m_shared[offset + 0x8000] = data;
			return; // [!]
		}
		else if (offset < 0x8800)
		{
			m_z80_private[offset & 0x7ff] = data; // SRAM
			return; // [!]
		}

		m_shared[offset ^ 0x8000] = data;
	}
	else
	{
		if (offset < 0x800)
			m_z80_private[offset] = data; // SRAM
		else
			m_shared[offset] = data;
	}
	return;
}



(Second)

* (from schematics) the TEST input of the 8088 (active low) is wired to
IRQ_COMM_PTR_INTR_L - the built-in 7201 COMM/Printer interrupt.

This is used for on board tests (WAIT loop). See previous text about the unimplemented loopback.


We really should fix the comm and printer in- and outputs to get the LK201 keyboard back on track. Unfortunately I have no clue how to set 8251 baud rates or program the MPSC.

So, what is left? A list of registers still unmapped in 'rainbow.c':

Code:
[06] : MPSC bit rates (see page 21 of PC 100 SPEC)
[0e] : PRINTER BIT RATE REGISTER (WO)

[40]  COMMUNICATIONS DATA REGISTER (MPSC)
[41]  PRINTER DATA REGISTER (MPSC)
[42]  COMMUNICATIONS CONTROL / STATUS REGISTER (MPSC)
[43]  PRINTER CONTROL / STATUS REGISTER (MPSC)


Mirror registers (?) not correctly serviced in LK201:

Code:
0x12 R/W
':lk201:lk201_cpu' (0313): unmapped program memory read from 0012 & FF
':lk201:lk201_cpu' (0392): unmapped program memory read from 0012 & FF
':lk201:lk201_cpu' (0C7A): unmapped program memory read from 0012 & FF

':lk201:lk201_cpu' (0104): unmapped program memory write to 0012 = 00 & FF
':lk201:lk201_cpu' (0185): unmapped program memory write to 0012 = 40 & FF
':lk201:lk201_cpu' (0392): unmapped program memory write to 0012 = 01 & FF

0x13 Read
':lk201:lk201_cpu' (0112): unmapped program memory read from 0013 & FF

0x16 WRITE
':lk201:lk201_cpu' (0110): unmapped program memory write to 0016 = 81 & FF
':lk201:lk201_cpu' (0177): unmapped program memory write to 0016 = 00 & FF

0x17 R/W
':lk201:lk201_cpu' (0114): unmapped program memory read from 0017 & FF
':lk201:lk201_cpu' (0181): unmapped program memory write to 0017 = A7 & FF

0x1A READ
':lk201:lk201_cpu' (0175): unmapped program memory read from 001A & FF

0x1B READ
':lk201:lk201_cpu' (0179): unmapped program memory read from 001B & FF


Any hints are welcome! Thanks!

@R.Belmont: you made interesting statements back then

Are there new developments (or old code not yet in GIT)...?

It is unlikely i will be able to fix anything related to the 8251 / MPSC.
smile
Posted By: Bavarese

Re: Requirements? - 09/30/15 01:23 PM

Real Life Syndrom caught me.

I recently found a backup / copy of the "Rainbow 100 Home Page" (by Jeff Armstrong ~ 2003) on ClassicComputers.

If anyone wants to contribute to the Rainbow, this is a good place to start.

What next?
The VT100 subsystem needs an overhaul, or a more general approach (see my comments in vtvideo.c).

@Lord Nightmare: how do you dump an open collector chip (arbitrator)?
Posted By: Lord Nightmare

Re: Requirements? - 10/01/15 03:08 AM

Re-doing vtvideo.c was on my list of stuff to look into, since a project which wanted to integrate some VT100 stuff from MAME/MESS had a license issue with that file (It is GPLV2+ unlike the rest of the vt100 stuff which is BSD; I may need to roll back to an older vtvideo.c from before the license was changed to GPLv2+ as a starting point, unless I can get the contributors to agree to relicense just that one file as 3BSD.)
The DEC rainbow-specific files were not an issue here (and can stay GPLV2+), just the shared vt100-and-rainbow shared video file, vtvideo.c

In fact, since the DEC video ASICs support both interlaced and non-interlaced video, it may or may not be worthwhile to re-write vtvideo.c from scratch anyway, once we have core interlace support working (which I believe is being worked on by Judge).


Anyway, dumping open collector proms isn't too hard: use 20kohm resistors from the prom output pins to vcc(+5v) while dumping. Your programmer may or may not already have internal pull-up resistors on the data bus, so it might not even be necessary.

LN
Posted By: Bavarese

Re: Requirements? - 10/02/15 05:57 PM

Err, the license was set to GPL after Miodrag asked me in May. I am fine with BSD if this single file slows down development.

The only thing i am uncomfortable with is that people make money by using source code developed in our spare time. Guess a license disclaimer won't stop them...

What was the project you were working on? smile

If there is in fact a rewrite, i am eager to test corner cases i found on the Rainbow-100 (SQUINT, for example, acts like a 'killer poke' on the Commodore CBM).

Some quick notes about the present state of vtvideo -

Code:
- 'interlaced mode' isn't fully understood 
- there are now 2 separate 'device_resets' (...) and
- there is the occasional 'break;' for the VT-100 (see list of unimplemented features in source code)

 'WRITE8_MEMBER(vt100_video_device::dc012_w)'
 'case 0x0c' (..)
 'case 0x0f' (..)
Posted By: Lord Nightmare

Re: Requirements? - 10/02/15 07:12 PM

Hmm. I'll take a look, I was hoping the vt100 tech manual might explain what the dc012 registers all do...

LN
Posted By: Bavarese

Re: Requirements? - 10/03/15 08:58 PM

The VT180 Technical Manual helped a lot (EK-VT18X-TM_001 VT180 Technical Man Feb83.pdf).

Most of the timings are present. Chapter 6 covers the inner details of the DC011 and DC012 in painstaking accuracy.

That said, the present, character oriented code works reasonably well (at least the Rainbow 100 path, which could be generalized).

Different termination characters on VT terminals shouldn't pose a problem smile








Posted By: rfka01

Re: Requirements? - 12/21/15 12:03 PM

Originally Posted By rfka01
News from Jeff Armstrong:

Quote:
I'll have to look at the 190 ROMs, but I'm pretty sure they're unlabeled. In the meantime, I was able to transplant the Turbow-286 card and ROM into another Rainbow and managed to get the system to boot (still having serious issues, though).

I've attached the two ROM dumps. I'm pretty sure that ROM1 is the stock 100B ROM, although my system has a ClikClok installed in between ROM1 and the board (I doubt that'd make a difference in the ROM dump). ROM0 is labeled: "TBSS 1.3" on line 1 and "3ED4" on line two (a checksum perhaps?).

I do have hi-res versions of the Turbow pictures somewhere. I'll have to look, but they should be accessible via the gallery I host. The chips aren't overly interesting, except that there does appear to be a GAL, which will make emulating it a pain. I remember reading that one of the chips, a 286-to-8088 adapter chip, was quite exotic at the time.

I'll let you know when I find the pictures and check for Rainbow 190 ROM labels.


https://dl.dropboxusercontent.com/u/55419307/DEC%20Rainbow%20turbow-286.zip


Earlier in this thread I had posted information from Jeff Armstrong about his TurboW 286 CPU card ... a few weeks ago Rainbow stuff turned up on Ebay that included manuals and disks for the TurboW, the ClikClok RTC module and other things. Here are the scans of the manuals and Teledisk images of the disks, if I get



I'll add Kryoflux dumps as well.

ClikClok Manual

Suitable Systems Hard Disk Solution

TurboW-286

Windows Adaptation Kit

Assorted Software
Posted By: Bavarese

Re: Requirements? - 12/29/15 12:07 PM

Thanks for the manuals. TRB286IN.TD0 is a valid CP/M disk and contains TURBOW.COM and TURBOW.CMD.
Unfortunately, 6 other images appear to be broken when i try to mount them under DOS 3.10 ("bad unit error reading drive B"):

Code:
X RBHDREM.TD0 
X SSIHDINS.TD0
X CLIKCLOK.TD0
X DOS310.TD0 
X DOS310SP.TD0 
X RBADAPKT.TD0 : crashes with "FATALERROR: Incorrect layout on track 0 head 0, expected_size=50000, current_size=88368 " 
(TD0 format violation?)


From my experience, it is better to read old disks on the original RX50 drive with the help of Jeff's RBIMG. This results in a plain sector image (no error info, though).

PC-HD drives tend to find errors on disks that are perfectly readable on a well-maintained RX50.

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.
Posted By: rfka01

Re: Requirements? - 12/29/15 10:35 PM

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).
Posted By: crazyc

Re: Requirements? - 12/29/15 10:54 PM

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).
Posted By: Bavarese

Re: Requirements? - 01/01/16 01:21 PM

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



Posted By: crazyc

Re: Requirements? - 01/01/16 03:00 PM

Then just swap the m_no_interrupt and m_fire_trap if blocks and check for m_no_interrupt before interrupt(1).
Posted By: Justin

Re: Requirements? - 01/03/16 07:37 PM

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.
Posted By: Bavarese

Re: Requirements? - 01/04/16 11:23 AM

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.
Posted By: R. Belmont

Re: Requirements? - 01/04/16 01:50 PM

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.
Posted By: Lord Nightmare

Re: Requirements? - 01/04/16 06:16 PM

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
Posted By: Bavarese

Re: Requirements? - 01/04/16 06:37 PM

@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.
Posted By: bsdimp

Re: Requirements? - 01/28/16 07:15 PM

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.
Posted By: Lord Nightmare

Re: Requirements? - 01/28/16 10:01 PM

IIRC the only ROM completely missing which is necessary for accurate emulation from a Rainbow 100B is the z80 arbitrator PROM 23-090B1, which is an MMI6308 256x8 Open Collector PROM at location E13 (E11 on the Rainbow 100A, both share the same part). The other missing roms are bios/firmware language roms, and we have one of the 5 known sets dumped. It would be nice to dump the other four, though.


In other words:

We have the two video PROMS, 23-023B2 and 23-056B2.

We have the video PAL 23-117J5 at E88/E93 (two pals on the board, both have the same contents).

We have the 23-037E3 Character set rom.

We have the 23-022E5 (main Firmware) rom.

We have the following language roms:
23-020E5 (German, French, English)


We're MISSING the following language roms:
23-015E5 (Dutch, French, English)
23-016E5 (Finnish, Swedish, English)
23-017E5 (Danish, Norwegian, English)
23-018E5 (Spanish, Italian, English)

We're MISSING the z80 arbitrator PROM:
23-090B1


If any of the roms/proms/pals in your machine have numbers different to the ones listed above, let us know!
Note that for pals and proms, DEC usually only printed the last 5 digits of the part number on the PROM/PAL itself, so the part may have stamped on it somewhere something like "WB8146 // 058B1" (where // is a newline) for 23-058B1

We're also missing ALL of the Rainbow 100A roms: firmware, language, character set, proms, pals. everything.

LN
Posted By: Bavarese

Re: Requirements? - 01/29/16 03:34 PM

Nice to see another competent person on board.

First, we would be glad to have additional source code or commented BIOS listings for this system.

Even with unoffical patches applied and a lot of tweaking, the rainbow.c driver misbehaves under DOS 3 and CP/M ("write error").

I hit a brick wall when it comes to 100% accurate floppy emulation. Some keywords: consistent floppy writes, contended memory, insertion of Z80 WAIT states during floppy I/O.

Drop me a line of you are interested in an unofficial build or the header files currently needed to get a working system...

Read support for floppies, hard disk emulation, and ClikClok are already built in. But there is still a lot to do ;-)
Posted By: bsdimp

Re: Requirements? - 01/29/16 08:55 PM

Originally Posted By Lord Nightmare
IIRC the only ROM completely missing which is necessary for accurate emulation from a Rainbow 100B is the z80 arbitrator PROM 23-090B1, which is an MMI6308 256x8 Open Collector PROM at location E13 (E11 on the Rainbow 100A, both share the same part).
LN


I have the 100B. Years ago, I bought a 100A used, but along the way I parted with it. I don't recall now when or why or how, but I think it was at least 15 years ago. So I can't help there.

I found the "Shared Memory Arbitrator" on the sheets, and located the part. I was thinking that I could pop it out and put it in a reader, but no such luck. I can see why you don't have this part. It is soldered into place and I'm loathe to take it out of the circuit. The circuit around it is also a bit complicated, which may frustrate efforts to read it in sutu. Mine is tagged with "6308-1J P8346 \\ LM8438 090B1" if that matters.

This is the first time in years I've looked at the inside of my unit. It's clean and looks good. So the next step is to power it up when I can get a few minutes and round up the right cables... That will let me read the disks I have. The RX-50 will connect to a PC floppy controller, and I have a couple of machines that still have that in them if I can't get this to power up for some reason... I'm taking it slow turning it on after so long since the last time...

The stickers over all the EEPROMs on the boards are blank. I didn't write down the part numbers, though. I should have taken pics while I had it apart to examine later. If I take it apart again, I'll do that.
Posted By: bsdimp

Re: Requirements? - 01/31/16 03:31 AM

I have a friend that may have a Rainbow 100A. Is there a way to dump the EEPROMs that is useful from MS-DOS's debug? I'd normally expect that I could just dump a memory range. If so, I can lookup the debug commands and try them on my 100B and go over to my friend's house and snag them from him. Any suggestions / accumulated wisdom before I dive in?
Posted By: Lord Nightmare

Re: Requirements? - 01/31/16 08:19 AM

Depending on the memory map you may be able to dump the whole firmware and language roms from dos DEBUG, but it is probably best to do with an eprom programmer.

Also, we'd need pictures of the chip labels anyway to determine what firmware revision the machine has.

LN
Posted By: Vas Crabb

Re: Requirements? - 01/31/16 11:07 AM

I'm pretty sure the program ROM for it is only visible to the Z80, not the main CPU. You might be able to somehow trojan it out, but that would require finding/exploiting a bug in it.
Posted By: Bavarese

Re: Requirements? - 01/31/16 04:12 PM

You should be able to dump the BIOS within DEBUG.COM (from DOS).

Ranges on a Rainbow-100 A are:

ROM (FA000-FBFFF) (E89) 8 K
ROM (FC000-FDFFF) (E90) 8 K
ROM (FE000-FFFFF) (E91) 8 K

The character ROM [E98] 2732 (4 K) can't be accessed this way.

Unverified:
Code:
C:\> DEBUG

-N DEC.BIN (resulting file will be named DEC.BIN)

-R BX (set BX=0000H/CX=6000H as count of bytes to write, 00006000H = 24K)
BX 0000
:0000
-R CX
CX 0000
:6000


-M FA00:0 6000 0100 (copy 24K from FA00:0 to offset 0100 in local segment)

-W 0100 (write from offset 0100 in local segment)
Writing 6000 bytes

-Q


Derived from instructions for IBM-PC computers -
http://www.mess.org/dumping/dump_bios_using_debug
Posted By: bsdimp

Re: Requirements? - 01/31/16 11:22 PM

Originally Posted By Lord Nightmare
Depending on the memory map you may be able to dump the whole firmware and language roms from dos DEBUG, but it is probably best to do with an eprom programmer.

Also, we'd need pictures of the chip labels anyway to determine what firmware revision the machine has.


It's really super easy to open the machine and take a photo, then grab the ROMs via debug. My friend may allow me top open it up and take a picture. I doubt he'd allow me to pull chips. He's doing me a favor as it is, since he's not touched this machine in 20 years except to move it...

Warner
Posted By: bsdimp

Re: Requirements? - 02/01/16 04:12 AM

Originally Posted By Vas Crabb
I'm pretty sure the program ROM for it is only visible to the Z80, not the main CPU. You might be able to somehow trojan it out, but that would require finding/exploiting a bug in it.


The Z80 on the Rainbow comes up in reset. The 8088 has to put its program in it, and take it out of reset. The boot roms are mapped only on the 8088 side. In fact the only thing the Z80 is attached to, apart from the shared memory and the 8088 interrupt line is the floppy drive.

But I also have Z80 compilers and assemblers if that's helpful. I didn't see anything on the prints, though, that could easily be read back from the Z80, with the possible exception of the Z80 memory arbitrator PROM, though that's a long-shot at best given the machinations one would have to go through to toggle the different address lines and chasing down where they all go... I'm not sure they all go to something that's readable by one or the other of the CPUs.
Posted By: bsdimp

Re: Requirements? - 02/04/16 02:54 AM

Woot! My friend has agreed to lend me his 100A. More to follow.
Posted By: Bavarese

Re: Requirements? - 02/04/16 09:10 AM

A word of warning: i cannot vouch for the correctness of the above DEBUG instructions. You might have to alter the M(ove) statement.

The RAM range (0100 ...) given is possibly occupied by DOS

Last time i tried in our emulation, the dump was littered with incorrect bytes (hell, i can't even rule out bugs in the emulated hard disk interface).



At least the 100-B uses an internal BIOS checksum, so we'll soon find out if the dump is correct. Hope there is time for a second shot, just in case smile

@bsdimp: please check your messages.
Posted By: Bavarese

Re: Requirements? - 02/04/16 05:07 PM

@R.Belmont & O.Galibert: i made a partial disassembly of the Z80 part (located at the end of the Rainbow-100 B BIOS).

Sector reads & writes are handled there - as far as the BIOS is concerned.

Perhaps we find out what's wrong with the timing?

https://dl.dropboxusercontent.com/u/37819653/BANNISTER/Z80_DISASSEMBLY__2016_02_04.html
(you may want to search for WRITE_SECTOR)

Thanks for having a look.
Posted By: bsdimp

Re: Requirements? - 02/06/16 04:38 PM

Originally Posted By Bavarese
@R.Belmont & O.Galibert: i made a partial disassembly of the Z80 part (located at the end of the Rainbow-100 B BIOS).

Sector reads & writes are handled there - as far as the BIOS is concerned.

Perhaps we find out what's wrong with the timing?

https://dl.dropboxusercontent.com/u/37819653/BANNISTER/Z80_DISASSEMBLY__2016_02_04.html
(you may want to search for WRITE_SECTOR)

Thanks for having a look.


I don't suppose there's a central repo (ala github or similar) that contains the accumulated disassembly of these ROMs?

Warner
Posted By: R. Belmont

Re: Requirements? - 02/06/16 10:15 PM

I don't know of one, but I think it'd be great if someone wants to set one up. It's not like HP will care.
Posted By: Bavarese

Re: Requirements? - 04/08/16 08:48 AM

@bsdimp: heard that developers are about to remove BSD support (unless somebody jumps in). For more details please have a look at the personal message sent to you.

We are still interested in the 100-A ROM - partly because older software like DOS 2.05 misbehaves. It could well be the ROM :-)

I could provide the most current ROM / Z80 disassemblies in return, together with IDA sources.

There are no plans to put them into version control, so i'd be glad about a mirror site...
Posted By: shattered

Re: Requirements? - 04/08/16 08:13 PM

Originally Posted By R. Belmont
I don't know of one, but I think it'd be great if someone wants to set one up. It's not like HP will care.


https://github.com/shattered/retro-bios

PRs welcome.
Posted By: Bavarese

Re: Requirements? - 04/09/16 06:10 PM

For now, I made a pull request concerning the main README. It would be helpful if we had a separate directory for DEC disassemblies (*.html output from IDA).

Binary files can't be uploaded to Github, so i am a bit concerned that the IDA base file gets out of sync with future changes (to the HTML).

Do you have an advice where to put them? smile


Posted By: shattered

Re: Requirements? - 04/09/16 08:04 PM

How big are these binaries? Git LFS should handle them in any case -- https://github.com/blog/2069-git-large-file-storage-v1-0
Posted By: Bavarese

Re: Requirements? - 04/26/16 04:13 PM

@shattered: please create a folder "dec100b", because i can't...

I recently uploaded the Z80 disassembly (from February) to the repository available under https://github.com/shattered/retro-bios.

The binary for that code can be found at the end of the upper, language specific ROM.


If a Z80 guru has a look at it, i'd be happy. I still think the code tries something weird we don't emulate.

At times, the Z80 controls the 8088 (CP/M) and sometimes it's the other way round (DOS). So it's not a strict master-slave relationship.


It could also be a much simpler problem with floppy emulation (overruns when writing because of unemulated WAIT states), who knows?
Posted By: R. Belmont

Re: Requirements? - 04/26/16 04:51 PM

Unemulated wait states causing data overruns/underruns on a machine with a 17xx FDC would be borderline fraud on the part of the hardware engineers. It makes sense on the Apple II where the software *is* the FDC, but the 17xx has a ton of ways you can sync without counting cycles.
Posted By: Bavarese

Re: Requirements? - 04/26/16 05:05 PM

Well, DEC manuals state the FDC code has a 'sweet spot' (whatever that tells us). I may have to look that paragraph up.

(i dont want to argue...)

Found a description of the wait state logic, as described by DEC:

(Technical manual, PDF page 115)

WAIT logic (DUELL schmatics, saved from Shoutbox):


Sorry for the bad quality.
Posted By: Edstrom

Re: Requirements? - 04/26/16 07:33 PM

I believe that MAME currently doesn't do dynamic wait states, so if the software depends on it, it propably needs to be faked somehow by the driver.

I have a similar problem with the lack of DTACK for the 68K which can stretch the access time when accessing slow devices. I'd really like to see a propert DTACK working but I am not even close to that level of understanding yet.
Posted By: R. Belmont

Re: Requirements? - 04/26/16 08:00 PM

68k Macs have some magic where you can do a DWORD read of the 5380 SCSI controller and it'll freeze the processor via DTACK until 4 bytes come in over the SCSI bus. That's the situation where no DTACK is fatal. If it's just causing a wait state, you can m_maincpu->adjust_icount(cycles) to add more cycles to the access. (the # of cycles must be *negative* to have a wait state, a positive number makes the CPU effectively speed up on access instead ;-)
Posted By: Edstrom

Re: Requirements? - 04/26/16 08:46 PM

Ahh, interesting, that might help to implement VME bus accesses too, I'll have a look at it.
Posted By: Bavarese

Re: Requirements? - 05/26/16 08:04 PM

Command $1C (SEEK_WITH_VERIFY) does not work as intended.

The diagnostic routines (RX50 DIAG.DISK) appear to use it extensively for READ and WRITE tests. Where is the bug? smirk

https://dl.dropboxusercontent.com/u/37819653/BANNISTER/SEEK_WITH_VERIFY_FAILS_1.jpg

https://dl.dropboxusercontent.com/u/37819653/BANNISTER/SEEK_WITH_VERIFY_FAILS_2.jpg

Hint: there is a disassembly of the main BIOS routines for the Z80 at

https://github.com/shattered/retro-bios/tree/master/dec-rainbow100b

Search for WRITE and 1Ch.
Posted By: Bavarese

Re: Requirements? - 05/28/16 10:09 AM

A SEEK_WITH_VERIFY (command $1c) ends with FORCE_INTERRUPT (c=d0) instead of SCAN_ID. I cant figure out why.

Output from log file ("IRQ REQUEST OBTAINED" stems from my own driver)
..
[:fd1793x] SEEK_WAIT_STEP_TIME_DONE
[:fd1793x] SEEK_MOVE
[:fd1793x] SEEK_WAIT_STEP_TIME_DONE
[:fd1793x] SEEK_WAIT_STABILIZATION_TIME_DONE
[:fd1793x] SEEK_DONE
[:fd1793x] SEARCH_ADDRESS_MARK_HEADER in case SEEK_DONE
[:fd1793x] Initiating command d0 <------------- ???
[:fd1793x] Forced interrupt (c=d0) <------------- ???
...

_SHOULD_ LOOK LIKE THIS:

[:fd1793x] SEEK_MOVE
[:fd1793x] SEEK_WAIT_STEP_TIME_DONE
[:fd1793x] SEEK_WAIT_STABILIZATION_TIME_DONE
[:fd1793x] SEEK_DONE
[:fd1793x] SEARCH_ADDRESS_MARK_HEADER in case SEEK_DONE
[:fd1793x] SCAN_ID <<<< ----------------
[:] FLOPPY - IRQ REQUEST OBTAINED: TRUE <<<< ------------ OK
[:] FLOPPY - IRQ REQUEST OBTAINED: false
Posted By: crazyc

Re: Requirements? - 05/29/16 06:02 PM

I can't get it to boot at all. Is there some procedure to make it work?
Posted By: Bavarese

Re: Requirements? - 05/30/16 08:51 AM

Thanks for jumping in. Just activate the keyboard workaround, as follows:

Code:
#define FORCE_RAINBOW_B_LOGO
#define KEYBOARD_WORKAROUND
#define KBD_DELAY 8    // (debounce delay, increase if necessary)

Necessary header files (important):
https://dl.dropboxusercontent.com/u/3781..._2016_05_30.zip

Without it, emulation stops with fatal ERROR 13 (keyboard stuck). R.Belmont already has spent considerable time on this one, and might know more.

Note that the workaround patches the BIOS heavily. It is the only way to get the machine going (for now).

- because the workaround disables standard BIOS procedures, you will also need a proper NVRAM file for 832 K:

https://dl.dropboxusercontent.com/u/37819653/BANNISTER/nvram_832.zip

Please set max. RAM accordingly in DIP settings (RAM = 832K; important).

- The RX50DIAG image is very valueable when testing. Especially READ and WRITE tests (available under INDIVIDUAL TESTS, with key 3, then 4 for FLOPPY TESTS) and also SYSTEM INTERACTION - because it hangs emulation.

https://dl.dropboxusercontent.com/u/37819653/BANNISTER/rx50diag.td0

- Force interrupt ($D0 or $D4) kicks in sooner or later, and SEEK_WITH_VERIFY or SCAN_ID fails (see RX50DIAG, again).

I suspect the Z80 runs too fast now (as I-O and MEMORY WAIT states aren't properly implemented; compare diagrams above).

There is an option to STALL_ON_WAIT for the Z80 and i experimented with it, without success...

- Work in progress (no guarantees) -

https://dl.dropboxusercontent.com/u/37819653/BANNISTER/rainbow.cpp

Of course, it could also be a silly bug i overlooked for years (e.g. interrupt handling and arbitration in update_8088_irqs @ rainbow.cpp changed at some point, and it is unclear if it is presently correct).


- To help with emulation, i have disassembled most parts of the Rainbow BIOS and put it on Github, available under

https://github.com/shattered/retro-bios/tree/master/dec-rainbow100b

Ask me anytime if you need more details smile

P.S.: help with untangling the monolithic driver would be very welcome
Posted By: crazyc

Re: Requirements? - 06/02/16 01:48 PM

I believe there should be an interrupt right here as enabling the transmitter should cause txrdy to go high. That interrupt ought to cause the reset command to be sent to the keyboard.

Edit: CTS is tied to ground on the schematic so it set to 0. That what is blocking the irq.
Posted By: Lord Nightmare

Re: Requirements? - 06/02/16 03:53 PM

Is the CTS pin on the uart supposed to be the direct CTS pin state (translated from rs232 voltage as described below in a direct fashion through a voltage divider) or the inverted state (through a discrete voltage divder+inverter or an inverting receiver)? This makes a big difference. The datasheet should say.

RS232 Voltage:
-3 to -25VDC is MARK (OFF for control lines like CTS, for serial tx/rx this is the '1' state)
3 to 25VDC is SPACE (ON for control lines like CTS, for serial tx/rx this is the '0' state, and if held this way for more than 8/9 bit cycles counts as a serial BREAK))

MC1489 is an example of a quad rs232 receiver.

LN
Posted By: crazyc

Re: Requirements? - 06/02/16 04:26 PM

It's shown as connected directly to ground and thus in active state (as it's an active low pin).

Edit: Here's the schematic page. There's no rs232 voltages involved, it's all TTL 0-5V stuff.
Posted By: Bavarese

Re: Requirements? - 06/03/16 12:25 PM

I recall a TEST/LOOPBACK circuit in 8088 (port 0x0A). It was discussed in

http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=103331&page=20#number95139

- but it is not implemented in our present source (Git).

Bit 5 redirects one output to another input during inital tests, and is unique to the Rainbow.

In my understanding, serial, printer and keyboard are tested in one large loop, so that interfaces must be fully functional (and redirectable by bit 5). As things stand now, this is not the case (else errors 40 and 60 for serial/printer would be absent at boot time).

Another indication: 8088 registers 0x02, 0x06, 0x0e are not implemented in 'rainbow.cpp' (unless i missed a super secret fork).

@R.Belmont: please forgive my stubbornness smile



(CLICK TO ENLARGE IMAGE; circuit in upper left corner)

Posted By: Just Desserts

Re: Requirements? - 06/03/16 02:33 PM

Tell you what, since Bitsavers is a public website, how about you send us a link to what's in the address bar of that barely-readable screenshot? smile
Posted By: Darkstar

Re: Requirements? - 06/03/16 02:41 PM

Here you go: page 17
Posted By: crazyc

Re: Requirements? - 06/05/16 10:30 PM

Here's where I'm at WRT the floppy.

First line 2010 should have the logic reversed force_read set is true. That changes error 12 - not read to 28 - rx50 board failure. That error is caused here. The head load line is shown in the schematic here but you can see on the next page it isn't pushed out to the drive. Page 3 seems to show that the motor for the selected drive is enabled implicitly by the head load line going high. The question I have though is what is happening with the Z80 though. I'd guess that the head load status bit on the 1793 isn't being set until the motor is up to speed (which would be reflected by the ready line if it weren't forced high on line 274 of the disassembly) which is possible as that bit is the HLD line anded with HLT, but the schematic doesn't seem to reflect that.
Posted By: Bavarese

Re: Requirements? - 06/06/16 09:06 AM

Thanks for sorting out the Rainbow driver smile
Sorry, i dont have deep links on Bitsavers for you.

(see circuit at bottom of screenshot)
https://dl.dropboxusercontent.com/u/37819653/BANNISTER/HLD%20-%20HLT%20-%20MOTOR%20ON.jpg

Source: Field Maintenance Print Set / MP-01722-01 from 1984 where the schematics of the RX50 controller can be found (scroll to end of document).

https://archive.org/details/bitsavers_decrainbowwSchematicJul84_3508632

Page 231 of the OCR version of Rainbow Technical Manual (pc100tm1_text) explains how the Head Load Circuit works -

- Disk present in the selected drive and the door is closed (DISK P H)
- drive is selected and the spindle motor is turned on (MPWR SEL H)

From the RX-50 Dual _Diskette Drive_ Specs:

Head settling time: 30 ms (maximum value)
Head load time: 30 ms (maximum value)

Source : QV069-GZ 100+ 100B Technical Documentation Apr85

That's about it all i could find.
Posted By: Lord Nightmare

Re: Requirements? - 06/08/16 01:44 AM

z80 arbitrator prom is dumped now, so we should now have absolutely everything we need to fully emulate this.

P.S. I notice during bootup that it displays all character sets on the top 2 rows of the screen for a bit before erroring out. Is it trying to read the character set rom using the diagnostic loopback stuff?

LN
Posted By: R. Belmont

Re: Requirements? - 06/08/16 02:04 AM

Nope, the displayed errors are for the serial port loopback - the POST doesn't do the bit-serial video reading.
Posted By: Lord Nightmare

Re: Requirements? - 06/08/16 04:29 AM

So, here's what the two loopback bits do, explained in a table:
Code:
Loopback bits     | These inputs below will connect to
                  | the signals in the chart below
DiagLoop PortLoop | CommRxD  PRTRxD  KBDRxD VidCLK PRTCLK
------------------+--------------------------------------
0        0        | CommRCV  PRTRCV  KBDRCV MASCLK PRTRxTxC
0        1        | CommTxD  KBDTxD  PRTTxD MASCLK PRTRxTxC
1        0        | CommRCV  PRTRCV  KBDRCV 250Khz 500Khz
1        1        | CommTxD  VIDOUT  PRTTxD 250Khz 500Khz

inputs:
CommRxD = EIA/RS232 uart receive pin
PRTRxD = printer uart receive pin
KBDRxD = keyboard data uart? receive pin
VidCLK = DC011 video asic clock
PRTCLK = printer uart serial clock for rx/tx

signals:
CommRCV = EIA/RS232 port rx pin (after going through mc1489?)
CommTxD = EIA/RS232 uart transmit pin
PRTRCV = printer port db25 rx pin (after going through mc1489?)
KBDTxD = keyboard data uart? transmit pin
KBDRCV = keyboard data rj11 jack receive pin
PRTTxD = printer uart transmit pin
MASCLK = master (and video) clock
500Khz = 500Khz clock
PRTRxTxC = printer baud clock (configurable)
250Khz = 250Khz clock

EDIT: The state of the two loopback pins (as well as the nvram 'program' and 'recall' bits, and the 'reset' bit) can be read back from the i/o register 0x6 as well as written. oddly, the schematic seems to show that the bit order is reversed between read and write, but this could be a drafting error on the schematic. Three bits are write only, when read back they read as a constant set by 3 jumpers on the board.

LN
Posted By: Bavarese

Re: Requirements? - 06/08/16 08:09 AM

Jumpers are emulated - and available from the 'DIP switches' GUI as W13,W14 and W15. Judging from the ROM code the 3 bits were used to branch into factory test code at boot time (and elsewhere).

https://github.com/shattered/retro-bios/...3-022e5-00#L747

As most jumpers drastically alter the code flow i havent found a practical use yet (except for folks able to write custom BOOT ROMs).

P.S.: i would not bother too much about the tests at boot time, now the keyboard showstopper is gone (see latest Github entries).

RX50 diagnostic test disk offers more unsettling insights (floppy 'individual test' claims that SEEK_WITH_VERIFY is broken etc.) Possible fixes there could also help TRS-80 users, see WD 1793 problems described by Robbert
Posted By: Lord Nightmare

Re: Requirements? - 06/08/16 04:15 PM

And of course I forgot one label on my chart above:

VIDOUT = video output from DC011 video ASIC
Posted By: crazyc

Re: Requirements? - 06/10/16 02:34 AM

CP/M finally.


This only works if the index pulse irq is suppressed when the fdc is busy. I'd like to know if there are any other examples of currently working machines/software when enables the index pulse irq before submitting to make sure it doesn't break anything.
Posted By: rfka01

Re: Requirements? - 06/10/16 07:24 AM

*opens virtual bottle of beer*

Cheers!

Great news ... but the case of the missing irq is strange indeed ... maybe something with the esoteric RX50 drives?
Posted By: R. Belmont

Re: Requirements? - 06/10/16 07:55 AM

That actually makes some sense that the index pulses wouldn't be passed on while the FDC was busy, but yeah it definitely needs a lot of regression testing.
Posted By: crazyc

Re: Requirements? - 06/10/16 07:00 PM

I can't find any other software which even enables the index pulse irq much less is regressed with this change. There are just so many machines with fd197x fdcs though, I can't test them all.
Posted By: Edstrom

Re: Requirements? - 06/10/16 08:21 PM

board config option maybe, with default as the old way?
Posted By: crazyc

Re: Requirements? - 06/11/16 03:12 PM

The old fd197x emulation had many per-machine hacks. Don't really want to go there again.
Posted By: Bavarese

Re: Requirements? - 06/16/16 07:16 PM

Hello,

have tracked down a weird CPU bug: if i do a soft reboot from within SETUP with CTRL-SETUP (a key combination from the the manual) the Z80 corrupts the 808x address space with stack data.

What i found out:

* BIOS begins an extensive memory test (BITTEST_AX) -

https://github.com/shattered/retro-bios/...-022e5-00#L3931

* problem gets visible at this location:

https://github.com/shattered/retro-bios/...-022e5-00#L4175

- BX is current address
- AL contains XOR result of correct and actual value

Z80 writes to $07f0/$07f1 (reflected at 808x offset $87f0/$87f1).

RESULT: ERROR 19 Main Board RAM (0-64K)

Why does the Z80 interfere with the memory test?

There is a reasonable suspicion the ZFLIP flag is set or handled wrongly. I just cant find where...

P.S.: floppy test on the DIAG.DISK (from 'indiviual tests') now aborts with a 'Z80 response error'. Coincidence?

Any ideas? :-)

Screenshot of Z80 caught in the act:

https://dl.dropboxusercontent.com/u/37819653/BANNISTER/Z80_writes_to_8088_memory.jpg
Posted By: Lord Nightmare

Re: Requirements? - 06/16/16 08:23 PM

are the flags reset to their appropriate values in device_reset? if anything is only set in device_init and not _reset, and/or is not reset properly by whatever the ctrl-setup reset function does (does it somehow activate one of the reset lines on the board itself thru an i/o port, sort of like how the RESET opcode on the 68000 causes the reset pin to output 5v?)

LN
Posted By: rfka01

Re: Requirements? - 06/16/16 08:37 PM

(Unrelated to Bavarese's problem):
If you run the rainbow driver compiled from latest git, you get

Code:
Fatal error: install_ram_generic: In range ed000-ed0ff mirror 1f00, mirror touches a set address bit, did you mean f00 ?
Posted By: Bavarese

Re: Requirements? - 06/16/16 08:48 PM

@Rfka: comment out the mirror on the NVRAM. Delete the third and fouth (zero) parameter of the RTC memory handlers.

@LN: the soft reset jumps to F4003 in lower BIOS. I have yet to find a difference to the normal (power on) check.

All is done in software. The MHFU or watchdog flag oftenly delivers wrong values and could be responsible.
Posted By: Bavarese

Re: Requirements? - 06/18/16 11:07 AM

I need to check if the 8088 acknowledges vertical interrupt requests. Unfortunately there are no good examples with this CPU...

There are some instances (Apollo, Amstrad) where a config statement like

MCFG_CPU_IRQ_ACKNOWLEDGE_DRIVER(amstrad_state,amstrad_cpu_acknowledge_int)

is used. Is this the way to go...? It seems i have overlooked a precondition, cause i cant get the syntax right.

P.S.: i want to mimic the VERT INTR L output from the DC012 display controller which clears (or rearms) the hardware watchdog. smile
Posted By: rfka01

Re: Requirements? - 06/20/16 05:58 AM

Recently in the SB:

Quote:
crazyc: Meanwhile the VT240 is sapping my will to live.
Lord Nightmare: crazyc: I don't have access to a vt240 to dump the pals/proms, sorry


I only have a VT320, and the link that I had already posted here earlier,

Quote:
Hi LN,

looks like we have got the ROM ... it's 23-054E7 in this directory:

http://www.dunnington.u-net.com/public/DECROMs/

and the pcb pic at

http://www.vt100.net/dec/vt320/pcb

shows one ROM.


has changed to http://www.dunnington.info/public/DECROMs/, and one directory level up there's also DECPROMS

No VT240 though which you were after originally ...
Posted By: Lord Nightmare

Re: Requirements? - 06/20/16 06:31 AM

We have the vt240 roms (two versions, in fact, of perhaps 3 or 4 total) dumped, but we do not have dumps of the 5 or 6 pals/proms on the pcb itself, which might be required for emulation to work correctly.

LN
Posted By: crazyc

Re: Requirements? - 06/21/16 01:29 AM

Originally Posted By Bavarese
MCFG_CPU_IRQ_ACKNOWLEDGE_DRIVER(amstrad_state,amstrad_cpu_acknowledge_int)

is used. Is this the way to go...? It seems i have overlooked a precondition, cause i cant get the syntax right.

Yes, that's right. You have to use set_input_line without a vector and return the vector from the ack function.
Posted By: bsdimp

Re: Requirements? - 06/22/16 05:58 PM

Good news.... I have finally obtained the 100A from a friend... I'll try to dump the ROMs when I get time next week.
Posted By: rfka01

Re: Requirements? - 06/23/16 06:04 AM

Never seen one in the flesh ... erm ... rapidly yellowing plastic smile

So ... great news! Thanks!
Posted By: rfka01

Re: Requirements? - 06/25/16 11:37 AM

There's a lot of interesting stuff on US Ebay at the moment ... shipping to Germany is prohibitively expensive though ...

http://www.ebay.com/itm/Vintage-DIGITAL-...GYAAOSwMNxXbCCC

http://www.ebay.com/itm/MICROSOFT-FORTRA...PMAAOSwzJ5XbAIC

http://www.ebay.com/itm/DIGITAL-COMPUTER...H4AAOSwbYZXbAQD

http://www.ebay.com/itm/1984-Graftwriter...mrXYgF-i5-zVESg

There's more, but this stuff would be great to have.
Posted By: Darkstar

Re: Requirements? - 06/25/16 04:07 PM

Wow, that's an impressive lot... if it wasn't that expensive to ship them overseas I'd bid on them. But maybe someone in the US can grab them and ship them over to your place for scanning/dumping? Or to Al Kossow...
Posted By: ssj

Re: Requirements? - 06/26/16 01:03 AM

$50 for shipping a bunch of disks? That's ridiculous, but unfortunately it's very common for US sellers to ask such amounts to ship overseas.
Posted By: Lord Nightmare

Re: Requirements? - 06/26/16 05:03 AM

I can easily image all of those disks, and am in the US...

LN
Posted By: rfka01

Re: Requirements? - 06/26/16 08:01 AM

How about this:

Each of our resident DEC aficionados could pledge an amount via PN to LN.

LN could bid on that team's behalf, receive and image the disks, maybe Al could take care of the scanning of the manuals ...
Posted By: Darkstar

Re: Requirements? - 06/26/16 02:30 PM

Well, I would definitely pledge a few bucks if LN is interested in doing this
Posted By: Bavarese

Re: Requirements? - 06/27/16 07:37 AM

I would also want to donate (if someone in the US can manage it).

The first bunch of disks seems most interesting. GraftWriter (last item) is rare, but definitely not worth 400 dollars.

What about copy protection? Lots of original business titles (Lotus & others) were in fact copy protected.

When we imaged RFKA's disk collection, i made *.FDI images (MFM ? with sampled index pulses) and later heard that MESS/MAME uses an incompatible internal format.

So i'd like to ask: is there a standard procedure?

Manuals are also important, though i think most Lotus & Microsoft titles were direct PC ports (often minus graphics)...

On another note, some small companies over here wrote individual business solutions. We now have (600 or 800 dpi) scans of the docs, but are uncertain if anyone cares enough to host non OCR'ed pages in German ... smile
Posted By: Darkstar

Re: Requirements? - 06/27/16 08:08 AM

Originally Posted By Bavarese
So i'd like to ask: is there a standard procedure?

I'd say the best action would be to create raw flux dumps with one of the many hardware dumpers that support it (KryoFlux, DiscFerret, ...) with at least a couple revolutions for each track, and from that you should be able to reconstruct any disk format and/or copy protection out there.
Posted By: rfka01

Re: Requirements? - 06/28/16 07:49 AM

LN doesn't seem enthusiastic about this as he did neither reply here nor answer my PM asking him to get involved.
Any other regulars here who would agree to bid on the stuff up to the amount pledged by others?
Posted By: Lord Nightmare

Re: Requirements? - 06/28/16 05:18 PM

Wait, I didn't get any PMs. What's going on?

EDIT: Re: Bavarese:
.FDI is one of those 'weird' flux formats we don't support YET, but I don't see any reason why someone couldn't add support for it. It is a somewhat complex format since it can represent tracks as pure flux, or in higher level (MFM/GCR) blocks, or as cooked data(i.e. what 'dd' would spit out). Info about the format can be found at http://www.oldskool.org/disk2fdi/support.html

LN
Posted By: rfka01

Re: Requirements? - 06/28/16 06:36 PM

LN, I must apologize: seems I have managed to send myself a PN without including you ... sorry for implying you were not interested.

It's all explained in the thread above, and if you're willing to bid on the stuff, I'll send a real message pledging an amount.

Robert
Posted By: Lord Nightmare

Re: Requirements? - 06/28/16 06:44 PM

I'm willing to bid on it, sure. If the disks are standard RX50 disks they can be easily imaged. Documentation might be more difficult to scan, though, it depends on the binding.
Posted By: rfka01

Re: Requirements? - 06/28/16 07:30 PM

PM sent (really) smile
Posted By: rfka01

Re: Requirements? - 07/01/16 09:34 AM



Quote:
Bavarese: You must specify "-c none" for no compression at the command line (chdman)
[...]
Bavarese: >chdman64 createhd - c none - chs 153, 4, 16 - ss 512 - o RD50_ST506.chd
Bavarese: (for a 5 MB hard disk). Be careful with DOS FDISK and large HDs, use WUTIL (especially when you specifiy a HD with more than 4 heads)
Bavarese: CCPM and DOS 3.1 cant cope with more than 32 MB partitions BTW


Shoutbox saved for posterity ... should probably end up in the Wiki
Posted By: Bavarese

Re: Requirements? - 07/01/16 10:04 AM

Additional info from the driver i plan to remove (to reduce bloat):

Code:
// DEC RD TYPE (MByte) CYL ---- HEADS ---- MODEL (typical)
// DEC RD50 (5 Mbyte): 153 cyl. 4 heads -- ST506
// DEC RD51(10 Mbyte); 306 cyl. 4 heads -- ST412
// DEC RD31(20 Mbyte); 615 cyl. 4 heads -- ST225
// DEC RD52(32 Mbyte); 512 cyl. 8 heads -- Q540 [!]
// DEC RD32(40 Mbyte); 820 cyl. 6 heads -- ST251 [!]
// DEC RD53(67 Mbyte); 1024 cyl.8 heads -- 1325 [!]
// [!] More than 4 heads. Prepare with WUTIL and / or DSKPREP.

// SIZE RESTRICTIONS
// * HARDWARE:
//      WD1010 controller has a built-in limit of 8 heads / 1024 cylinders.
// * BOOT LOADERS:
//   - the DEC boot loader (and FDISK from DOS 3.10) initially allowed a maximum hard disc size of 20 MB.
//   - the custom boot loader that comes with 'WUTIL 3.2' allows 117 MB and 8 surfaces.
// * SOFTWARE:
//   - MS-DOS 2 allows a maximum partition size of 16 MB (sizes > 15 MB are incompatible to DOS 3)
//     [ no more than 4 partitions of 8 MB size on one hard disk possible ]
//   - MS-DOS 3 - and Concurrent CPM - have a global 32 MB (1024 cylinder) limit
//   - a CP/M-86-80 partition can have up to 8 MB (all CP/M partitions together must not exceed 10 MB)


Next step would be the hookup of serial/printer interfaces and the 7201.

I feel like i have to reinvent the wheel smile

How do i actually use the internal terminal (invoked from the GUI)...?

Driver WIP: https://dl.dropboxusercontent.com/u/37819653/BANNISTER/2016_07_01_Rainbow_CPP.txt
Posted By: R. Belmont

Re: Requirements? - 07/01/16 12:11 PM

Why would you remove useful info like that?
Posted By: Bavarese

Re: Requirements? - 07/01/16 01:22 PM

Hmm... sizes can be taken from manuals, old MSDN pages or Wikipedia with some effort.

I am forced to make a sacrifice for readability, as our driver approaches 100 kilobyte.

The monolithic nature of the Rainbow driver is a problem. In part, because i dont know squat about slot devices.

Quite certain the ST506 / WD1010 code could be modularized (or even replaced by something more complete, for example MFMHD)...

Posted By: Just Desserts

Re: Requirements? - 07/01/16 03:22 PM

Originally Posted By Bavarese
Hmm... sizes can be taken from manuals, old MSDN pages or Wikipedia with some effort.


That's no reason to remove it from the driver. In fact, given how often URLs change, it is (if anything) an argument for keeping it in the driver. We put useful info like that directly in the drivers for a very good reason, which is that MAME is a documentation project. Choosing to actively remove documentation seems to run against that.

Originally Posted By Bavarese
I am forced to make a sacrifice for readability, as our driver approaches 100 kilobyte.


That means the driver should be split across multiple files, not that you should be removing useful documentation from it. smile
Posted By: Lord Nightmare

Re: Requirements? - 07/01/16 06:27 PM

You could stick the more detailed documentation as a giant comment or comments in a .h file if you really want to but that may hurt readability.

If you end up doing that, the .cpp file should note that further documentation is in the .h file.

LN
Posted By: etabeta78

Re: Requirements? - 07/01/16 08:04 PM

but there really is no need to move the info from its current location, so why are we discussing the point so much? wink
Posted By: Bavarese

Re: Requirements? - 07/02/16 04:32 PM

[7201 emulation / serial setup]
Now i tried to follow the instructions RFKA gave on the DMV thread (page 9), only problem is that nothing gets through.

Details:
- 7201 config statements were added to the Rainbow driver (hopefully correct). The IRQ (IRQ_COMM_PTR_INTR_L,) is firing.

- i try to connect Putty to the bitbanger on 127.0.0.1, port 10000. The Rainbow runs in Terminal Mode (T key after boot) where it mimics a VT100/VT102 (more or less)...
Unfortunately nothing happens ...

- no virtual comm port is installed (and the platform is Windows 10).

Driver - work in progress (2016-07-02):
https://dl.dropboxusercontent.com/u/37819653/BANNISTER/2016_07_02_Rainbow_CPP.txt

https://www.dropbox.com/s/16uhf9gmlobh9wd/2016_07_02_Rainbow_CPP.txt?dl=0

Command line / invocation:
mess64 -window -debug rainbow -frameskip 10 -bitbngr socket.127.0.0.1:10000

The printer is difficult to get working (even with a patch), so i concentrate on the serial interface for now.
Posted By: Duke

Re: Requirements? - 07/02/16 08:22 PM

You're missing the null modem device that needs to be connected to the RS232 port.
Posted By: Bavarese

Re: Requirements? - 07/03/16 06:30 AM

The null modem is present (without it, i guess the bitbanger wouldn't start) -
Code:
MCFG_DEVICE_MODIFY("rs232_a")
MCFG_SLOT_DEFAULT_OPTION("null_modem")

What is missing?

- i have not the faintest idea how baud rates are programmed into the 7201 (except there is an extra bitrate register at port $06 in 8088 I/O space with 2 half bytes for up and download rates ... $F means 19200, $E 9600 etc.).

- there are also 5 unemulated status and 4 control bits in 'comm_control_r' and 'comm_control_w'

Question is, how do i set individual port bits (DTR, RTS) or get the status of DSR, CTS, RI...?

The Rainbow documentation suggests the 808x CPU has direct control on these bits via 'comm_control_r' and 'comm_control_w'.

Thanks for any clues

Posted By: Edstrom

Re: Requirements? - 07/03/16 08:42 AM

http://bitsavers.trailing-edge.com/pdf/n...Description.pdf for a start and then at some point split it out as separate device driver
Posted By: Duke

Re: Requirements? - 07/03/16 10:19 AM

Sorry, I didn't see that you added the null-modem directory in the machine config, usually it's added as a slot device like '-rs232 null_modem'.

You can set the upd7201 control lines with device->cts_w() etc. To get the status, you need to hook up a callback in the machine config.
Posted By: crazyc

Re: Requirements? - 07/03/16 01:03 PM

You need to call m1_r() in update_mpsc_irq() for the irqs to work properly.
Posted By: Bavarese

Re: Requirements? - 07/03/16 07:40 PM

Saved from the Shoutbox.

Code:
(...) the 7201 is externally clocked like the 8251, and you aren't doing that.

That's why there's the separate 8088 port to set the baud rate, because there's a completely separate baud rate generator 


Schematics of baud rate generator:
https://dl.dropboxusercontent.com/u/37819653/BANNISTER/BAUD_RATE_GENERATOR.jpg

Standard smc/com5016T dual baud rate generator, see vt100.c and vk100.c for examples where it is used (says LN)

@shattered: here ist the link to the latest source. The m1_r (IRQ acknowledge) fix Cracyc mentioned is missing...

https://dl.dropboxusercontent.com/u/37819653/BANNISTER/2016_07_02_Rainbow_CPP.txt

Thank you!
Posted By: Bavarese

Re: Requirements? - 07/03/16 09:40 PM

Shattered's partial fix from Sunday is at

https://gist.githubusercontent.com/shattered/37137526ff3ad171f0d38f8d19b6ce3c/raw/e5faa78250b14992d3c46dc4389bd16b7e954a3f/rainbow%2520haxx

Status: self test fails with "unsolicited interrupt" and "watchdog error" (16 = interrupts off).

Theory: serial redirection during self test fails.
Posted By: Bavarese

Re: Requirements? - 07/04/16 05:58 PM

The self test is bypassed by unmapping the MPSC and activating the handlers when everything is normal.

Now i can send data from the Rainbow to a Putty terminal. There is no transmission in the other direction, as far as i can see...

https://dl.dropboxusercontent.com/u/37819653/BANNISTER/2017_07_04_Rainbow_CPP.txt
Posted By: shattered

Re: Requirements? - 07/04/16 07:02 PM

flow control hack you've asked for -- https://gist.github.com/shattered/d48d429a20f7062473331eaff7377a51

z80dart driver has to be modified to set/reset RTS as appropriate.
Posted By: Bavarese

Re: Requirements? - 07/05/16 02:23 PM

Thanks.

I tried with (FDXB setting in SETUP) and without flow control (FDXA setting).

Without, i can transmit from Rainbow to terminal - but not in the other direction. Diagnosis: receive overrun error in z80dart_channel::receive_data (line 1079)...

With flow control, the Rainbow locks up (WAIT LED lights) until i set FDXA in SETUP again.

Hint: do not set FDXC. It is a mode with a secondary 1200 bps line on the same port.
Posted By: Lord Nightmare

Re: Requirements? - 07/06/16 03:50 AM

Since we have the mcu dump for the older intel mcs-51 based LK201 which we do have full schematics for, would it make sense to make an 'lk201o' device, to make 100% sure we have a fully documented, emulated keyboard hookup?

LN
Posted By: Bavarese

Re: Requirements? - 07/06/16 09:49 AM

It would make sense. I hesitate to do so, for various reasons. One aspect is that i have to cut back my invest in MAME/MESS.
Posted By: Bavarese

Re: Requirements? - 07/07/16 03:39 PM

Today i promoted the Rainbow-100-B driver to working. I also added a fourth (PC double density) drive for better data exchange. Note that you will need IMPDRV3.SYS in CONFIG.SYS (and D: becomes unavailable).

The screenshot shows a Rainbow-100 B with amber monitor, mounted hard disk and real time clock. DC.COM (a fast, free Norton Commander clone) is running under CodeBlue (a 3rd party PC emulator). Most non-graphical applications work. cool

There is a FreeDOS image mounted on F: (you cannot boot that, before anyone asks)...



Noticed that DIPs are a bit garbled in newer builds. They used to be aligned according to the order of the DIP macros.

P.S.: the serial port still needs some love.

Posted By: Bavarese

Re: Requirements? - 07/08/16 12:45 AM

From the Shoutbox:
Code:
R. Belmont: Bav: if you're around, I have a question about your vtvideo patch. is the case 0x0b: meant to fall through into 0x0c? 

'0x0a' and '0x0b' are separate cases. Truth is, i changed the polarity of 'reverse_field' -late- to get correct colors (both in SETUP and the video test on the diag.disk).

Perhaps my idea of a reverse characters is wrong?

VT-180 specs, chapter 6-43 says: "reverse characters are (an) XOR of reverse video and reverse screen" and i came up with

Code:
invert = invert ^ m_reverse_field ^ m_basic_attribute;

..which looked good. There is also a separate logic to handle 'blank' space (bit = m_reverse_field ^ m_basic_attribute).

I spent quite some time to reconcile my code with the docs, and verify character attributes. There was even a truth table in the VT100 tech.manual i implemented (see reference a. below).

It should be possible to iron out the remaining bugs. I assume a complete rewrite might be overkill for a business machine.

REFERENCES:
a. complete truth table (for attributes) from TABLE 4-6-4 (in VT100 technical manual)
b. VT-180 manual 6-30 (for screen attributes)
c. VT-180 specs, chapter 6-43 (where multiple attributes are described
Posted By: Bavarese

Re: Requirements? - 07/11/16 06:15 AM

Saved from the Shoutbox:

Code:
Lord Nightmare: bavarese: vtvideo.cpp is incorrectly showing vt100 video as interlaced regardless of the setting of the config bit on setup page B

Lord Nightmare: i assume changing the setup bit should instantly take effect

Lord Nightmare: to get to vt100 setup page b: boot vt100, press f5 repeatedly until setup page A comes up, then press '5' repeatedly until setup page B comes up

Lord Nightmare: the meaning of the block of config bits at the bottom can be found on page 6-4 (PDF page 249) of 

http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/terminal/vt100/EK-VT100-TM-003_VT100_Technical_Manual_Jul82.pdf

Lord Nightmare: NEVERMIND, I screwed up, the interlace bit works PERFECTLY. I miscounted which field to change the bit in
Lord Nightmare: what doesn't seem to work is the 'inverse video' or white on black vs black on white bit, nor the AVO functions which should have "SETUP A"
 blinking and "to exit press setup" underlined, but that is most likely a vt100 driver issue, not a vtvideo.cpp prob

Lord Nightmare: so AVO support in vt100 driver is currently at least partially broken, if not completely.


Bavarese: VTVIDEO contains 2 sections. The VT100 section

vt100_video_device::device_start(),
vt100_video_device::display_char)

is essentially unchanged since 2009 and many features (48 line mode; soft scroll; intensity / 4 color palette, interlaced mode) are unimplemented there...

When i began, i lacked ROMs and experience, plus i have never seen a VT style terminal to this day. So i am unable to compare my interpretation of attributes with live hardware.

The Rainbow is my reference machine. It doesnt have an AVO as such, while it treats the basic attribute as inverse (*)

Once you * have * the larger picture, this approach appears inadequate and must be expanded (...somehow) smile

You could try to adapt the VT driver to use

'rainbow_video_device::display_char' and
'rainbow_video_device::device_reset()'

instead of the vt100_ (old, 2009 style) routines.

Evaluation of DC011 and DC012 (write) registers is mostly the same. Just take care of the extra 'break' statements in cases 0x0d and 0x0f (of routine dc012_w)...!

(*) P.S.: i think that a VT100 _with_ AVO interprets the 'basic attribute' as inverse, while one without treats it as _underline_.
Posted By: bsdimp

Re: Requirements? - 07/13/16 05:48 AM

Originally Posted By Bavarese
(*) P.S.: i think that a VT100 _with_ AVO interprets the 'basic attribute' as inverse, while one without treats it as _underline_. [/b]


I recall this being one of the (few) differences between running programs on the Rainbow and running them on the VT102 at work (which had the AVO stuff). It mattered only for one silly program I ran back in the day, but I can't recall what that was.

Warner

P.S. I'm back. I had to take a couple months off from this project, but I'm back now.
Posted By: Bavarese

Re: Requirements? - 08/04/16 12:39 PM

I have done some data forensics on weak disks. If you happen to have the unaltered, original file (or a dump of the IBM character set) please post it!

Most important is the lost Code Blue (IBM emulator) update - required for DOS 3.10b. Now comes with documentation, hints, and a key map -

1) https://dl.dropboxusercontent.com/u/37819653/BANNISTER/CODEBLUE_3.x_UPDATE_rev.20160804.7z
Note: CB3.EXE floating around has all mandatory and optional patches applied ('Yes' everywhere, 'fast' key repeat, IBM character ROM installed). My patch is better / more flexible smile

This update expects version 2.0 of CB.EXE (from 1987)...


IFormat & IDrive (with IFORMAT3, which had a harmless bad spot around offset $229D):
2) https://dl.dropboxusercontent.com/u/37819653/BANNISTER/IFORMAT_RECOVERED.7z


3) the fast, free Norton Commander clone written in assembly (Soeren Kragh, 1992) i used in the screenshot above.

(last download contains an untampered archive. Must be invoked via CodeBlue /V on the Rainbow, as it was written for PCs)
Posted By: Bavarese

Re: Requirements? - 08/04/16 02:10 PM

Post 3.10 patches from January 1990 for CodeBlue. Handles a bug in the keyboard routine. Also addresses users of international keyboards (January 1990).

Interesting because it lists (and somehow knows / patches in) all the various keyboards sold (mine for example, is a 'LK201-AG')...
Posted By: Bavarese

Re: Requirements? - 08/15/16 09:56 AM

(Question regarding screen macro)

How do i specify a second, totally independent graphical screen from within the rainbow. driver?

First screen is reserved for the on-board output (vt100 video, text only; working).

The 2nd (new) screen should be driven exclusively by the NEC 7220 display controller (accessed in several drivers like QX10, DMV, IF800 and VT240).

I now have implemented some of the extra logic on the Rainbow color graphics board, as well as the mandatory

UPD7220_DISPLAY_PIXELS_MEMBER( hgdc_display_pixels );

...and now cant figure out how to "set the screen". Is it

Code:
MCFG_UPD7220_SET_SCREEN("screen2")

 or 

MCFG_VIDEO_SET_SCREEN("screen2")

I'd also like to have a callback to set and clear the video interrupt on VSYNCs, similar to the VT100 (text only) video driver. For the vt100 video driver, it used to be something like

Code:
MCFG_CPU_VBLANK_INT_DRIVER("screen", rainbow_state, vblank_irq)
 MCFG_VT_VIDEO_CLEAR_VIDEO_INTERRUPT_CALLBACK(WRITELINE(rainbow_state, clear_video_interrupt))

Can you help me? Is there something obvious i overlooked?

Thank you very much,
Karl.

Errors i copied over from previous attempts:

Code:
Driver rainbow (file rainbow.cpp): 1 errors, 0 warnings
Errors:
   uPD7220 device 'upd7220': No screen specified for device ':upd7220', but multiple screens found

------------
On another occasion (different macro config):

MCFG_VIDEO_SET_SCREEN called on device ':screen2' with no video interface


Macro code for screen 1 and screen 2 (= preliminary):
Code:
/* video hardware */
MCFG_SCREEN_ADD("screen", RASTER)
MCFG_SCREEN_REFRESH_RATE(60)
MCFG_SCREEN_VBLANK_TIME(ATTOSECONDS_IN_USEC(2500)) /* not accurate */
MCFG_SCREEN_SIZE(132 * 10, 49 * 10)
MCFG_SCREEN_VISIBLE_AREA(0, 80 * 10 - 1, 0, 48 * 10 - 1)

MCFG_SCREEN_UPDATE_DRIVER(rainbow_state, screen_update_rainbow)
MCFG_SCREEN_PALETTE("vt100_video:palette")
MCFG_GFXDECODE_ADD("gfxdecode", "vt100_video:palette", rainbow)

MCFG_DEVICE_ADD("vt100_video", RAINBOW_VIDEO, 0)
MCFG_VT_SET_SCREEN("screen")
MCFG_VT_CHARGEN("chargen")
MCFG_VT_VIDEO_RAM_CALLBACK(READ8(rainbow_state, read_video_ram_r))
MCFG_VT_VIDEO_CLEAR_VIDEO_INTERRUPT_CALLBACK(WRITELINE(rainbow_state, clear_video_interrupt))

// ************************************************ SECOND video hardware (GDC-NEW) 

/* Devices  (GDC-NEW) */
	MCFG_DEVICE_ADD("upd7220", UPD7220, 8000000/6) // unk clock
//	MCFG_DEVICE_ADDRESS_MAP(AS_0, upd7220_map)
	MCFG_UPD7220_DISPLAY_PIXELS_CALLBACK_OWNER(rainbow_state, hgdc_display_pixels)

MCFG_SCREEN_ADD("screen2", RASTER)
MCFG_SCREEN_VIDEO_ATTRIBUTES(VIDEO_UPDATE_AFTER_VBLANK | VIDEO_ALWAYS_UPDATE)
MCFG_SCREEN_REFRESH_RATE(50)
MCFG_SCREEN_VBLANK_TIME(ATTOSECONDS_IN_USEC(2500)) // not accurate 
MCFG_SCREEN_SIZE(800, 240)
MCFG_SCREEN_VISIBLE_AREA(0, 800-1, 0, 240-1)

MCFG_SCREEN_UPDATE_DEVICE("upd7220", upd7220_device, screen_update)
Posted By: Duke

Re: Requirements? - 08/15/16 10:02 AM

You need to add a new screen with

Code:
MCFG_SCREEN_ADD("screen name", RASTER) ...


For the VSYNC there is a callback you can add:

Code:
MCFG_UPD7220_VSYNC_CALLBACK


EDIT: MCFG_VIDEO_SET_SCREEN needs to be added after your 7720 device in the machine config, not after the screen.
Posted By: Bavarese

Re: Requirements? - 08/18/16 03:24 PM

I am working on code for the circuitry DEC apparently added to the Graphics Option.

Six ports (0x50 to 0x55) seem to add functionality not present on the original NEC 7220, for example up to 4 bit planes, a color map, a scroll map (and more).

https://dl.dropboxusercontent.com/u/37819653/BANNISTER/GDC_and_EXTRA_PORTS.jpg

Currently, i dont know how to implement the Readback Latch (see path in red at right top) which provides 16 bits to the FIFO.

I see that Read, modify, write (RMW) cycles are unimplemented in upd7220.cpp... There must be a way to pipe back display data (orange) to the GDC. How is it done correctly?

There is also some logic involving a "pixel mask" - data apparently coming from the GDC (green arrow).

Thanks for insights,
Karl

https://dl.dropboxusercontent.com/u/3781...Guide_Jun84.pdf

[Click to enlarge block diagram]

Posted By: crazyc

Re: Requirements? - 08/18/16 03:38 PM

That looks quite similar to the vt240. You should look there for hints. You'll probably find it somewhat opaque though as the hardware is rather odd.
Posted By: Bavarese

Re: Requirements? - 09/14/16 09:01 AM

Thanks, Crazyc! I made some progress. Debugging is dead slow, plus i havent mastered palette and IRQ handling yet.

Some questions

How do i set up a second, independent palette for SCREEN 2?

Is there a way to speed up debugging under Visual Studio 2015 (i have quite a beefy laptop with a core I7 and an SSD, but it comes to a crawl with debug builds)...?

I added a macro statement for VSYNC
Code:
MCFG_UPD7220_VSYNC_CALLBACK(DEVWRITELINE("upd7220", upd7220_device, ext_sync_w)))

... but don't know where to put the actual IRQ code:

(something like)
Code:
if(m_GDC_MODE_REGISTER & GDC_MODE_ENABLE_VSYNC_IRQ)
	raise_8088_irq(IRQ_GRF_INTR_L);



(WIP: pacman ghosts on the right. No palette, no colors. Still some VRAM bugs)
Posted By: R. Belmont

Re: Requirements? - 09/14/16 12:27 PM

What version are you using that it's still called MESS? smile Any development done on something that old is going to be increasingly hard to port forward.
Posted By: crazyc

Re: Requirements? - 09/14/16 12:49 PM

If you build with SUBTARGET=mess you'll get a binary with MESS as the window title and the orange icon.

Quote:
I added a macro statement for VSYNC
Code:

MCFG_UPD7220_VSYNC_CALLBACK(DEVWRITELINE("upd7220", upd7220_device, ext_sync_w)))


... but don't know where to put the actual IRQ code:

(something like)
Code:

if(m_GDC_MODE_REGISTER & GDC_MODE_ENABLE_VSYNC_IRQ)
raise_8088_irq(IRQ_GRF_INTR_L);


You should create a WRITE_LINE_MEMBER in the driver just like any other line. The example you have there which writes back into the 7220 device is for machines (mostly the 9801) which have multiple 7220s and one drives the sync for the other.
Posted By: Bavarese

Re: Requirements? - 09/14/16 12:59 PM

Ok. As for the palette, there seems to be only 1 palette per machine, is that correct?

I dont see a machine which uses "palette2" or something similar. Is the GFXDECODE thing absolutely required / necessary?

Thanks again in advance.
Posted By: Duke

Re: Requirements? - 09/14/16 01:28 PM

You can have as many palettes as you want, MCFG_PALETTE_ADD adds one to the machine config.
Posted By: Haze

Re: Requirements? - 09/14/16 01:48 PM

just be aware that if you have multiple palettes you can't use the indexed screens, you have to use the rgb32 ones instead of ind16

it can get a bit messy.

also there's the core problem with multiple screens you might run into with complex setups, whereby if you have 2 screens running at different refresh rates one of them won't update properly (the partial update system gets very confused because it expects both the screens to end at the same time and if that isn't the case large parts of one screen end up not updating at all)
Posted By: Bavarese

Re: Requirements? - 09/16/16 04:41 PM

I now have implemented a stripped down version of the VT240 display code (no DMA scroll mode, no line erase mode...).

The rest turns out to be a lot harder than i thought.

Main problem: macros for VSYNC and PALETTE still appear to be wrong.
. So VSYNC IRQs do not fire and i can't get hold of the second palette.

Could an expert have a look?


P.S.: i added a bootable image, as well as the Pacman freeware for testing purposes. Pacman runs in medium resolution, on color ("pacman") and monochrome displays ("pacmono"). It was chosen because it needs no IRQs and follows well known patterns.

Invocation:
mess64 -window -debug rainbow -frameskip 10 -flop1 c:\msys64\_DISKS\bootbar.img -flop4 c:\msys64\_DISKS\FDSTD_COLOR.img


A newly invented DIP should, in theory, switch between grey shades on monochrome and R G B ("color mode"; the green gun is actually wired to MONO out from the _graphics option_).

Dual monitor support (R G B plus Mono) was added late in the design. Few commercial programs (AutoCad 2.6) support it. A homebrew cable and a patch to avoid the internal switch ('diagnostic_w', m_ONBOARD_GRAPHICS_SELECTED) usually make the difference..

Although not entirely correct, my proposition is to restrict NEC GDC7220 output to the right hand side.

Reference:
https://dl.dropboxusercontent.com/u/3781...Guide_Jun84.pdf
Posted By: crazyc

Re: Requirements? - 09/16/16 05:11 PM

The vsync callback line needs to be below the 7220 DEVICE_ADD line.
Posted By: Bavarese

Re: Requirements? - 09/16/16 05:30 PM

Thanks so far.

VRAM accesses are still botched, and the keyboard now misbehaves often with ERROR 13.

Will report later. smile

Posted By: crazyc

Re: Requirements? - 09/16/16 06:39 PM

It took a while for me to get the vram writes correct on the vt240. There were many subtle details that needed to be correct. Since the rainbow looks to be very similar but not identical I'd expect there to be some extra wrinkles.
Posted By: Bavarese

Re: Requirements? - 09/17/16 09:43 AM

@Crazyc: i am curious. How did you figure out the various bit masks (for "offset") in VRAM_W? Via schematics?

I am thinking of statements like
Code:
WRITE16_MEMBER(vt240_state::vram_w)
{
...
	offset = ((offset & 0x30000) >> 1) | (offset & 0x7fff);
Posted By: crazyc

Re: Requirements? - 09/17/16 02:18 PM

In https://archive.org/stream/bitsavers_dec...ge/n20/mode/1up address line 14 is ignored while 15 and 16 are routed to other circuitry.
Posted By: Bavarese

Re: Requirements? - 09/19/16 05:27 PM

Palette and Vsync statements are in place now.

I had modest successes with freeware games PACMAN, DOODLE and SCRAM (the last one displays a monochrome intro pic with too much space in between).

Text seems totally broken (right to left). Guess "hgdc_draw_text" must be implemented, first eek



Could someone have a look at the offsets in "vram_w" and "hgdc_display_pixels", please?

https://dl.dropboxusercontent.com/u/37819653/BANNISTER/2016_09_19_RAINBOW_CPP.txt

Without schematics or intimate knowledge of the 7220, it seems too much trial & error (i do not even own the hardware).

Perhaps there a circuit diagram of the Rainbow-100 graphics option (part number should be 54-15688 or PC1XX-BA)...?
Posted By: Bavarese

Re: Requirements? - 09/20/16 09:29 AM

We actually have schematics here.

I'd appreciate hints, though (see previous post) smile

There is also a 'new' piece of DEC hardware i encountered during my search, the so-called Mini-Exchange. It was a serial 8 port serial X switch with DOS support (Xattach, XDetach). Sort of an early Laplink.

Thanks to all uploaders (wink Rfka).
Posted By: Bavarese

Re: Requirements? - 09/23/16 12:39 PM

Wow, 2 of 13 tests from Graphics Diagnostic Disk pass (presence detect, FIFO). smirk

Ok, the PAL array already dumped does some modifications on bits before they are written back to the bit map memory (guess: ALU / plane select).

Now i am unsure about the 7220 clock. Is it really (E31) 31.188 Mhz / 4 = 7.797 Mhz ...?

A 31.188 quarz does not seem to exist in XTAL.H...

Datasheets says "7220 is available in 4.0 , 5.0, and 5.5 Mhz versions, 7220A in 6.0, 7.0, and 8.0 Mhz"




Pic: there is a plethora of good tests for different 7220 modes (complete with explanations and loop option...just press ALT for Help or L to loop after a failure)
Posted By: R. Belmont

Re: Requirements? - 09/23/16 01:19 PM

That diagnostic could be useful for sorting out some of the dark corners of the 7220 emulation.
Posted By: Just Desserts

Re: Requirements? - 09/23/16 05:11 PM

Originally Posted By R. Belmont
That diagnostic could be useful for sorting out some of the dark corners of the 7220 emulation.


True, but that "erratic interrupt" failure is slightly alarming. Depending on how demanding the tests themselves are, it could be a real pain to get them all passing, which is something that I'm encountering currently with the Fairlight CMI driver.
Posted By: Bavarese

Re: Requirements? - 09/27/16 07:41 PM

The NEC 7220 is rather complex, and several features are missing in the current code (RMW cycles for example).

I now have a playable version of SCRAM... only the diagnostic disk is unimpressed. There is certainly a long way to go.

BTW, i found a good article by Guido Dampf (from 1986, in German) about the inner workings of this chip, with Turbo Pascal source. An abridged version in English is somewhere, too.

Crazyc, do you happen to know it?

I plan to submit my current status soon and hope for improvements by others. As stated above, Pacman, Doodle and Scram offer fine test cases (apart from the GDC diagnostic disk).

Posted By: Al Kossow

Re: Requirements? - 09/27/16 07:54 PM

This makes me want to poke a the quad qbus 7220 board that came in the Calcomp branded Terak that I have again. Problem is I have no software for it.
Posted By: crazyc

Re: Requirements? - 09/27/16 07:59 PM

Originally Posted By Bavarese
The NEC 7220 is rather complex, and several features are missing in the current code (RMW cycles for example).
We do do rmw cycles for everything except the case where the whole byte/word is written directly, we just to them too fast (which may need to be fixed for the 9801 but nothing else seems to be that timing sensitive).
Originally Posted By Bavarese
Crazyc, do you happen to know it?
German? Nope.
Posted By: Lord Nightmare

Re: Requirements? - 09/27/16 08:50 PM

Originally Posted By Al Kossow
This makes me want to poke a the quad qbus 7220 board that came in the Calcomp branded Terak that I have again. Problem is I have no software for it.


I have some terak-branded disks i dumped a long while ago from a box I found at university, but I think they hold word processing stuff for the exidy sorceror disk drive expansion box, not terak stuff. Just reused 8" disks.

LN
Posted By: Bavarese

Re: Requirements? - 10/17/16 06:53 PM

New findings:
- the "status register" test (#4) pokes the GDC command port $57 circa 28 times with 0x22 (WDAT ?), then queries the status port $56. It then expects a FIFO_FULL response (instead of EMPTY..as it is now).
Is it the flags or the timing?

- later tests of the GDC diagnostic disc often invoke RDAT with mod = 02 (unimplemented ?).

On the positive side, the scroll test (#2) looks good, so we are at 23 % now ;-)

Posted By: crazyc

Re: Requirements? - 10/17/16 07:22 PM

WDAT occurs instantly so the FIFO will never fill. It should probably be converted to an execute device so each operation can take the proper number of cycles.

RDAT with a mod is undocumented and doesn't really make much sense so without testing on real hardware we can't know what to do with it.
Posted By: Bavarese

Re: Requirements? - 10/18/16 04:28 PM

Isn't RDAT documented on page 216 of the Programmers Reference from June 1984?

On another note, vector and hires modes show something - although parameters like direction (DIR) and X/Y (of lines and arcs) seem to be oddly 'reversed'. crazy

I have to override 'm_bitmap_mod' in UPD7220.CPP, otherwise figures never appear. WDAT 0x22 (see above) frequently sets RMW mode to 2, which zaps all bits. Sure, i haven't fully grasped how the extra hardware and the GDC interact..

Mastermind intro. Circles are OK. Arc over text should appear rotated 180 degrees to right (adjacent to character w)...


Graphics Demo. Text barely readable (X axis...), lines have wrong direction


(Solitaire, hires, with vector mode)
Posted By: crazyc

Re: Requirements? - 10/18/16 06:06 PM

Originally Posted By Bavarese
Isn't RDAT documented on page 216 of the Programmers Reference from June 1984?


I hadn't seen that doc just the nec doc which says nothing about the mod and the Intel clone doc which says mod must be 0.
Posted By: Bavarese

Re: Requirements? - 10/28/16 05:11 PM

Sorry, i didnt want to be nosey.

A new pull request is available on Github (Enhance DEC Rainbow 100 Option Graphics #1589).

It seems i am a bit at a dead end with the NEC GDC.

Perhaps someone more knowledgeable could have a look at vector mode and the odd FIG parameters - see section BUGS in #1589

Code:
+Interaction of Upd7220 and Rainbow.cpp:
+- FIG directions / params appear to be odd (lines go 45 degrees up or down instead of straight dir.),
+- RDAT with MOD 2 is unimplemented. WDAT appears to set "m_bitmap_mod" wrongly ("2" means all pixels will be reset)
...

Text looks funny too (see screenshots above) smile

Several assembly snippets and freeware games are here (ASM in folder EX32)
Posted By: crazyc

Re: Requirements? - 10/28/16 07:04 PM

Originally Posted By Bavarese
Sorry, i didnt want to be nosey.
If this is directed at me, I was just laying out the docs for why RDAT is like it is. It might be that the bytes are supposed to be cleared, set or complemented as they are read out but nothing says that anywhere.
Posted By: shattered

Re: Requirements? - 10/31/16 10:08 PM

Originally Posted By Bavarese
The self test is bypassed by unmapping the MPSC and activating the handlers when everything is normal.

Now i can send data from the Rainbow to a Putty terminal. There is no transmission in the other direction, as far as i can see...


I've changed z80dart_channel::receive_data to print fifo depth and apparently, the rx register is not being read -- maybe interrupt service routine does not run?

(this is from error.log when raibow is connected to remote loopback i.e. TCP echo service)
Code:
[:upd7201:cha] Z80DART ":upd7201" Channel A : Receive Data Byte '2f' (fifo -1)
[:upd7201:cha] Z80DART ":upd7201" Channel A : Receive Data Byte '2f' (fifo 0)
[:upd7201:cha] Z80DART ":upd7201" Channel A : Receive Data Byte '2f' (fifo 1)
[:upd7201:cha] Z80DART ":upd7201" Channel A : Receive Data Byte '2f' (fifo 2)
[:upd7201:cha] Z80DART ":upd7201" Channel A : Receive Data Byte '2f' (fifo 2)
[:upd7201:cha] Z80DART ":upd7201" Channel A : Receive Data Byte '2f' (fifo 2)
[:upd7201:cha] Z80DART ":upd7201" Channel A : Receive Data Byte '2f' (fifo 2)
[:upd7201:cha] Z80DART ":upd7201" Channel A : Receive Data Byte '2f' (fifo 2)
<...>
Posted By: shattered

Re: Requirements? - 11/01/16 07:36 PM

I've moved m_mpsc->m1_r(); into if() clause like so
Code:
    if (m_mpsc_irq == 0) {
        lower_8088_irq(IRQ_COMM_PTR_INTR_L);
        m_mpsc->m1_r();
    } else
        raise_8088_irq(IRQ_COMM_PTR_INTR_L);


and rx now works (f.e. from a TCP chargen service) but terminal is still broken -- it starts autorepeating first character you press.
Posted By: Bavarese

Re: Requirements? - 11/03/16 01:19 PM

Communication appears to work with 9600 baud, 8,N,1, (and XON/OFF) in both directions - for a short time.

After a few hundred (?) characters, sending from the Rainbow to Putty stops (in terminal mode T). A handshake problem?

Must admit i haven't checked out Edstrom's recent changes...

It would be nice if other bitrates than 9600 were possible. I heard the VT100 terminal emu works best at 4800 bps (given the slow main CPU, clocked at 4,81 Mhz).
Posted By: Edstrom

Re: Requirements? - 11/03/16 02:36 PM

Yeah, that's the problem, the fifo doesn't work as expected so when more than one character is still in the DART device the order is reversed as it implements a stack rather than a FIFO. So as long as the Rainbow reads out the characters "fast enough" the board driver should work but if the characters are arriving too fast, eg little time between the characters, big confusion may happen.

My change fixes that and it should potentially also fix a lot of other board drivers that relies on polled serial routines or that has lots of higher level interrupts delaying the readout. Also try higher bit rates as it may increase the space between the characters, depending on your typing speed.

You can cherry pick my PR and see if it helps, I think it will.
Posted By: Edstrom

Re: Requirements? - 11/04/16 01:24 PM

I just merged the new fifo code in z80dart driver, please test it and see if it makes a difference.
Posted By: Edstrom

Re: Requirements? - 11/06/16 11:57 AM

I have decoded the 7201 setup: http://pastebin.com/6eRL5kU5

It resets the 7201 a lot and it even touches synchronous modes for a while which is not supported by the z80dart but settles as follows:

Code:
 - CLOCK BIT: 00
 * :upd7201:chaB 00 <- 18  Channel Reset command (011b)
 * :upd7201:chbB 04 <- 4d  Odd Parity enabled, Async mode 2 stop bits, 16x clock
 * :upd7201:chbB 03 <- 41  Receiver enabled, 7 bit 
 * :upd7201:chbB 05 <- 28  Transmitter enabled, 7 bit, DTR inactive
 * :upd7201:chbB 01 <- 15  Interrupt on received character, Ext Status, status affect vector
 * :upd7201:chbB 02 <- 00  No DMA, Non vectored interrupts D4 D3 D2, p10=RTSB
 
 * :upd7201:chaA 00 <- 18  Channel Reset command (011b)
 * :upd7201:chaA 02 <- 10  Interrupt vector
 * :upd7201:chaA 04 <- 45  Odd Parity enabled, Async mode 1 stop bit, 16x clock rate
 * :upd7201:chaA 03 <- 41  Receiver enabled, 7 bit 
 * :upd7201:chaA 05 <- 28  Transmitter enabled, 7 bit, DTR inactive
 * :upd7201:chaA 01 <- 10  Interrupt on received character

ff to COMM.CONTROL REGISTER 

 * :upd7201:chaA 00 <- 01  


As you can see it expects 7 bit communications with odd parity enabled on both channels but only 1 stop bit on channel A, so try that. Handshakes should hookup RTSB and this is already done in the rainbow driver. I didn't try the terminal, what does your command line look like?
Posted By: Bavarese

Re: Requirements? - 11/06/16 01:06 PM

I use the bit banger on Windows with a cmd.line like
mess64 -bitbngr socket.127.0.0.1:10000

Then, i connect to 127.0.0.1 with Putty/Windows.

I actually cant get a connection at other speeds than 9600, plus i have to disable handshake everywhere (via our GUI, and in PuTTY/Windows, where i selected 8,N,1, 9600 and XON/OFF software handshake).

Additionally, i must set FDXA (no flow control) in Rainbow SETUP (press F3, page down, set 8N, 9600 for both directions, ESC to leave, then please perform a full reset cycle). smile

I can send text from the Rainbow to Putty in Terminal Mode (T), but as soon as the Rainbow _receives_ text sent from Putty, transmission stops (nothing can be typed anymore).

FDXB (full modem control) does lockup (no transmission, and printf on the console goes crazy while the Rainbow BIOS tries to poke register $06 [comm_bitrate_w] repeatedly... which seems incorrect).

I could not get hardware handshake on a real machine either (KERMIT/Rainbow <-> KERMIT/W95)...

Part of the problem could be that no handshake (FDXA) is less than ideal, and full handshake (FDXB) requires a modem like setup (Carrier Detect and all) from a BIOS perspective.
Posted By: Edstrom

Re: Requirements? - 11/06/16 02:08 PM

I need the exact command line to be able to duplicate what you are doing, and instructions on how to manage the machine, eg how do I enter the "Rainbow setup"? Are you talking about the MAME menu or a menu in the Rainbow graphical UI?

8N9600 is the same number of bits as 7O9600 so it would seem to work until you get parity error where the 7201 would do need to issue a Error reset command.
Posted By: Bavarese

Re: Requirements? - 11/06/16 04:32 PM

Rainbow SET-UP can be invoked by hitting key F3 (*), page down TWICE, set 8N, 9600 for both directions.



Navigate from setup page to setup page with PAGE DOWN, use cursor keys, change values with UP and DOWN.
Finally save all parameters with SHIFT-S (quit SET-UP by pressing F3).


(*) You may want to reassign F3 to another key. See DEC_LK201.CPP and this one

A full reset cycle is required according to the manual if anything is changed beyond TX or RX baud rates.

You could also use the NVRAM file here

The bitbanger setup was described by "Rfka01" in the DMV thread. He also used XON/OFF btw.

The difference to DMV is that the Rainbow does not have slots (and i also do not use a virtual port). So the command line really is:

mess64 -window -debug rainbow -frameskip 10 -bitbngr socket.127.0.0.1:10000

Full documentation for the DEC Rainbow 100 B is at

http://www.os2site.com/dec/rainbow/doc2/index.html

Let me recommend two manuals:

a. Technical Documentation from April 1985

b. Technical Addendum for 100-A and 100-B

Putty is not invoked via command line. Instead, it is set to match the parameters used in SET-UP. My system is Win 7 Pro 64 bit.

If other questions arise, it might be easier to ask Shattered. He helped me with the baud rate generator.
Posted By: Edstrom

Re: Requirements? - 11/06/16 05:29 PM

Thanks, so let me guess that you are using this command line:

mame64.exe rainbow -rs232_a null_modem -bitbngr socket.127.0.0.1:1234 -window

The information in this line that I needed is that you use the 'rainbow' model, not rainbow100a or rainbow190 and that you connect to rs232_a not the rs232_b, and that is why I asked.
Posted By: Lord Nightmare

Re: Requirements? - 11/06/16 05:36 PM

Technically the rainbow does have one slot: the fixed disk WD1010 controller card is optional inside. Its afaik the only card which can fit in said slot.

LN
Posted By: Edstrom

Re: Requirements? - 11/06/16 05:58 PM

Like the Mac SE Nubus slot, with room for a single Nubus card, but there were different cards of course.

I think I have the right hookup now, what am I expected to do at the putty terminal? I poke it and I get no characters going either way.
Posted By: Bavarese

Re: Requirements? - 11/06/16 06:16 PM

Oops, the section
-rs232_a null_modem
is missing in my invocation.

Instead, i see 4 lines in Rainbow.cpp saying
Code:
MCFG_DEVICE_MODIFY("rs232_a")
MCFG_SLOT_DEFAULT_OPTION("null_modem")

MCFG_DEVICE_MODIFY("rs232_b")
MCFG_SLOT_DEFAULT_OPTION("printer")


Putty connects directly to the bitbanger at 10000.





You may also have to specify "local echo" both in Putty and in Rainbow SETUP (on second screen after 1st Page Down).

This is also the place where the more obscure comms. features are hidden (Carrier Detect length, BREAK ...) smile

--- @Edstrom: if both machines are properly connected, you should be able to see what is typed on the other end.

(Putty requires an additional carriage return / line feed before it sends anything).

BUG: had to toggle "Handshake" On and Off in MESS' GUI (invoked by TAB) from time to time in my experiments (...).
Posted By: Al Kossow

Re: Requirements? - 11/06/16 06:16 PM

Originally Posted By Edstrom
Like the Mac SE Nubus slot


The SE had a processor direct slot which wasn't Nubus

SE/30 had a pseudo slot for video, and a PDS. Neither were Nubus

SI/CI had a PDS that could take a nubus adapter (basically the nubus interface chips from the Mac II on a card)
Posted By: Edstrom

Re: Requirements? - 11/06/16 07:08 PM

Thx Al, I have an SE and always thought it was a Nubus slot. smile
Posted By: Bavarese

Re: Requirements? - 11/20/16 04:03 PM

Originally Posted By crazyc
(...) I was just laying out the docs for why RDAT is like it is. It might be that the bytes are supposed to be cleared, set or complemented as they are read out but nothing says that anywhere.


Whenever DBIN is asserted on the 7220, a RMW cycle (memory access) takes place (display cycles are entirely seperate). Reading also means writing or updating & refreshing the memory (to "simplify external glue logic").

I assume RDAT works the same way as WDAT does - at least parameters look exactly the same for both (p.215 and 216 of the Rainbow Graphics Option Manual)

An external logic (named "Combiner" in Tony Duell's schematics (page 10) kicks in whenever the GDC's WRITE_MASK is set to all ones
Reference

It appears there are yet no hooks to change the bit mask before an update.

As i am no hardware guy, i have now disassembled most of the Graphcis Diagnostic Disk with IDA Free (and hope it clears things up) smile


Some unresolved questions keep bugging me:
- what does the Graphics MMU actually do (see schematics)...?

- the Graphics Option Manual from DEC talks about "synchronization of RMW cycles" (when writing to the special port 50).

Assumption: this simply sets the external WRITE_MASK to FFFF and sets the external ALU (a PAL16L8) to zero (for replace).

Comments are welcome.

P.S.: i have aquired (somewhat rare) German docs for the GDR clone of the NEC 7220 (U82720). Is Bitsavers interested in foreign language manuals?
Posted By: shattered

Re: Requirements? - 11/20/16 10:40 PM

Is it an exact clone? A few Robotron machines use it (A7150 in particular).
Posted By: Bavarese

Re: Requirements? - 11/21/16 01:18 PM

I can tell for sure it is pin-compatible and likely was "redesigned by looking at horizontal and vertical microsections / micrographs" (a standard technique employed in the GDR and mastered to perfection). (no first hand info, quote from related Robotron pages)

Known versions:
- U82720 DC04 (8,34 Mhz @ VIS3)
- less than 4 MHz clock: U82720 DC03 and DC02

U82720 veb mikroelektronik / Robotron (198x)
U82720 from Robotron (PDF in question)

Raw TIFs suited for OCR

VIS3 graphics card (GDR 19??)
VIS3 Beschreibung und Treiber (DOC)

The VIS3 package (above) contains lots of drivers and good documentation. Even the 4 plane mode (known from the Rainbow) is described...
Posted By: crazyc

Re: Requirements? - 11/21/16 05:42 PM



Posted By: Bavarese

Re: Requirements? - 12/05/16 03:51 PM

Thanks, Crazyc smile

First, there is a new version of the GDC diag disassembly.

A new pull request tries to address reentrance problems (after reset) and makes vertical scroll fully functional.

This lets you dive deeper into the reactor core in SCRAM and - more important - fixes the LIST command in DEC's version of GWBASIC (which was next to unusable)

Games that work well are MMIND (MasterMind), PACMAN, SCRAM, and GOTELO (Othello).

Programs with initialization / redraw / reentrance problems (invocation order matters, at least in emulation):
- CANON (high resolution + vectors),
- Solitaire (SOLIT.EXE) and
- GDEMO (from GRPHCS.ARC, interactive graphics interpreter from Livermore Labs 1985),
- plus the Monitor Aligment Test (from the GDC test disk).

There are some interesting cursor issues left. It all depends on the application (REGIS, GSX, GW-BASIC). In the 1st screenshot, the cursor block is invisible and leaves a one line trail behind). The 2nd one shows a scenario where cursor doesn't clear properly (high resolution game with REGIS TSR loaded) frown

GW-BASIC 2.01.01 (from DEC 1984) with Bad Robots source (medium resolution):


------------------------------------------------------------

Cursor artefacts in a high resolution REGIS-powered game (EMPIRE.EXE). Cursor should blink. Please ignore the wrong Hz value in screen 2 (already corrected).
Posted By: Haze

Re: Requirements? - 12/05/16 05:13 PM

I know you say ignore the wrong hz, but there is a MAME issue whereby if both screens aren't of the SAME hz you will have problems with screens not updating properly, including graphic trails.. you don't say what you corrected it to

so unless the correct frequency for both is the same (60?) and that's what you're running both at you'll run into core issues.
Posted By: Bavarese

Re: Requirements? - 12/05/16 06:05 PM

Is there a proper work around?

For example, two separate screens or switching to "Graphics Output" via GUI?

I remember your warning, and in fact the refresh is 50 or 60 Hz at text screen 1 (above) and 59.999 / 29.999 (interlaced) at bottom.

The cursor (trail) problem even occurs if i disable screen 1 completely. A custom layout with "side by side", "over under", "Text only" and "Graphics only" options is there.

An assumption made near line 1210 / CCHAR (cursor characteristics) @ Upd7220.cpp makes me confident it is no simple artefact.

For completeness, here the complete bug list included in the driver. Help is very much appreciated.

Code:
BUGS
- GDC diagnostic disk fails on 9 of 13 tests (tests 4 and 6 - 13). 

Details
a. (Rainbow driver) : interaction between DEC's external hardware and the NEC 7220 isn't fully understood (see page 173 of AA-AE36A)
   It is also unclear what port $50 actually does when it 'synchronizes R-M-W cycles' between NEC and DEC hardware.
   For now, we provide sane defaults for both vector and bitmap units without disturbing colors, display mode(s) or the NEC 7220.
b. the HBLANK / VBLANK ratio is plainly wrong (QUICK TEST / subtest #6),
c. IRQs are flagged as 'erratic' (QUICK TEST / subtest #12). 
d. (7220) : incorrect fifo stati are handed out (GDC reports FIFO_EMPTY instead of _FULL when QUICK TEST #4 floods the queue)
e. (7220) : RDAT with MOD 2 used extensively here, but unimplemented (modes other than 0 weren't documented by NEC or INTEL) 

Programs with initialization / redraw / reentrance problems (invocation order after reset matters, at least in emulation):
- CANON (high resolution + vectors), Solitaire (SOLIT.EXE) and GDEMO (from GRPHCS.ARC, interactive graphics interpreter '85),
  plus the Monitor Aligment Test (from the GDC test disk). 

Graphical games that work well: MMIND (MasterMind, after BMP logo), PACMAN, SCRAM, (G)OTELO.

UNIMPLEMENTED:
// - Rainbow 100 A palette quirks (2 bit palette... applies to certain modes only)

UNKNOWN IMPLEMENTATION DETAILS:
// 1. READBACK (hard copy programs like JOBSDUMP definitely use it. See also GDC diagnostics).  VRAM_R ?

// 2. UNVERIFIED DIVIDER (31.188 Mhz / 32) is at least close to 1 Mhz (as on the VT240, which uses a very similar design)

// 3. UPD7220 / CORE oddities: 
// 3.1. occasional redraw problems (only when screen 1 runs at 60 Hz and screen 2 at 29.99 Hz interlaced = HIRES ?).
// Quote from Haze: "if you have 2 screens running at different refresh rates one of them won't update properly
//                  (the partial update system gets very confused because it expects both the screens to end at the same time
//                  and if that isn't the case large parts of one screen end up not updating at all)

   3.2 pixels are stretched out too wide at 384 x 240 (not fixable in Rainbow driver, -keepaspect seems to have no effect)

Posted By: Bavarese

Re: Requirements? - 01/06/17 11:21 PM

The aspect ratio problem is fixed and all known ClikClok versions are supported.

Time for new ventures... Corvus hard disks (of type B/H) are now working under CP/M 1.x



I admit, that's a bit old skool smile

Once upon a time Corvus supported MS-DOS 2.x and CP/M 2.2 too. But are there any driver disks left?

There must have been an XDRIVE.SYS -DOS- device driver (mentioned in a Corvus PDF someone posted here).

Definitive -chs parameters for Corvus B/H hard disks are hard to come by, too (needed for Chdman)...

Al Kossow, to the rescue?
Posted By: Al Kossow

Re: Requirements? - 01/06/17 11:39 PM

Originally Posted By Bavarese


Time for new ventures... Corvus hard disks (of type B/H) are now working under CP/M 1.x...!

I admit, that's a bit old skool smile

Once upon a time Corvus supported MS-DOS 2.x and CP/M 2.2 too. But are there any driver disks left?


Al Kossow, to the rescue?


yea.. I have it somewhere. I have the manual sitting here too at least for Omninet support. Flat cable support should be somewhere, I worked with the guy who wrote the DOS driver at Corvus at Apple around 1987. I've got the CP/M driver on an 8" floppy

CP/M stuff is in bitsavers.org/bits/Corvus/Floppies/corvus1.tar

Posted By: R. Belmont

Re: Requirements? - 01/06/17 11:48 PM

From a2corvus.cpp:

5 MB: -chs 144,4,20 -ss 512
10 MB: -chs 358,3,20 -ss 512
20 MB: -chs 388,5,20 -ss 512

Those were taken from Corvus technical documentation on Bitsavers.
Posted By: Bavarese

Re: Requirements? - 01/07/17 12:37 AM

Thanks. There is a bit of confusion around the hard disks used.

The CP/M 1 tools shown in the screenshot only mention the (larger, later) type H drives.

How did Corvus achieve 20 sectors on MFM drives, by the way?
Posted By: Al Kossow

Re: Requirements? - 01/07/17 12:51 AM

Originally Posted By Bavarese
Thanks. There is a bit of confusion around the hard disks used.

The CP/M 1 tools shown in the screenshot only mention the (larger, later) type H drives.

How did Corvus achieve 20 sectors on MFM drives, by the way?


B drives used IMI 6 meg native flat cable drives
H drives are IMI 5006, 5012 or 5018 which are ST-412 and a formatter board

it is clocked at 11MHz

see corvus_mfm_decoder.c in Dave Gesswein's MFM emulator source for details of the sector format
Posted By: Al Kossow

Re: Requirements? - 01/07/17 01:01 AM

Originally Posted By R. Belmont
From a2corvus.cpp:

5 MB: -chs 144,4,20 -ss 512
10 MB: -chs 358,3,20 -ss 512
20 MB: -chs 388,5,20 -ss 512

Those were taken from Corvus technical documentation on Bitsavers.


hm.. that doesn't look right. H drives had 1,2 or 3 platter drives in them. you're missing the 6mb H drive, they have 306 cyls, and 2, 4 or 6 heads.

-- ah the 10 and 20 are the 8" "A Drive" values

Board revision B detected
Found drive at select 1
Drive RPM 3596.0
Primary transition period 180 ns, should be around 200
Matches count 24 for controller Corvus_H
Header CRC: Polynomial 0x8005 length 16 initial value 0xffff
Number of heads 6 number of sectors 20 first sector 0
Interleave (not checked): 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Drive supports buffered seeks (ST412)

No sectors readable from cylinder 306
Stopping end of disk search due to two unreadable tracks in a row
Number of cylinders 306, 18.8 MB
Posted By: Bavarese

Re: Requirements? - 01/07/17 09:57 AM

Yes, 306 cyls with 2, 4 or 6 heads are consistent with what i took from one of the many PDFs

Code:
Type H drives, used on the TRS 80-II and DEC Rainbow 100
6 MB :  -chs 306,2,20 -ss 512
11 MB:  -chs 306,4,20 -ss 512
20 MB:  -chs 306,6,20 -ss 512


I wasn't quite sure, given the 20 sector oddity...
Posted By: Bavarese

Re: Requirements? - 01/08/17 02:31 PM

Now that we emulate even exotic hardware from ancient times, i'd like to tackle long standing bugs smile

1. all hard disk boot loaders i tried crash our emulation (including, but not limited to latest WUTIL 3.2.x and DSKPREP).

It is possible to generate boot diskettes with DSKPREP for both MS-DOS and CP/M, yet neither 'autoboot' (from BIOS) nor a manual boot (W key) works correctly.

2. the ZFLIP flag or another Z80 register is wrong after CTRL/Setup (= standard method to warm boot the Rainbow)

I got some clues why 1. happens, and will report later smile
Posted By: Bavarese

Re: Requirements? - 01/18/17 05:39 PM

I have added info about 6 and 20 MB Corvus drives (and how to format / use them) under CP/M 86/80 version 1.

Al Kossow kindly provided driver source for Corvus on Lifeboat CPM 2.2, but this requires - more or less - skillful modification to work with DEC's CP/M 86/80 2.x.

There are wo obstacles: a specific patch address must be determined (RWMLOC & RWMDTA in old source from Maslin), and LDCOPY seems to be hard coded in version 2.x (will not write arbitrary loader files as in CPM 1). See HINSTALL.SUB:

(script from *, modifies 3 core CP/M 1.x files)
Code:
; CORVUS INSTALLATION DISKETTE IN A, CURRENT SYSTEM DISKETTE IN B
B:STAT B:*.SYS DIR
ERA B:Z80CCP.SYS
ERA B:Z80.SYS
ERA B:PRMTVPVT.SYS
B:PIP B:Z80CCP.SYS=A:HZ80CCP.SYS[V]
B:PIP B:Z80.SYS=A:HZ80.SYS[V]
B:PIP B:PRMTVPVT.SYS=A:HPRMTVPV.SYS[V]
B:STAT B:*.SYS SYS
B:LDCOPY A:HBOOT.LDR B:
; === THE DISKETTE IN DRIVE  B  HAS NOW BEEN CONFIGURED FOR USE WITH THE CORVUS DRIVE


Maybe one of the few remaining CP/M experts can have a look (Robert...)? smile
The TRS-80 variant uses the same type H drives, by the way...

http://www.retroarchive.org/maslin/disks/dec/
* http://www.retroarchive.org/maslin/disks/dec/drcdutil.zip
(Al Kossow's link, from Lifeboat CP/M 2.2):
bitsavers.org/bits/Corvus/Floppies/corvus1.tar
Posted By: bsdimp

VENIX Disks - 04/21/17 01:40 PM

Venix disks for the Rainbow have recently surfaced. I've been able to read them all, and have a running Venix on my real Rainbow 100B. Will leverage that to make sense of the files that I was able to read on the Rainbow. More to follow shortly.
Posted By: R. Belmont

Re: VENIX Disks - 04/21/17 02:32 PM

The more obscure Unix variants, the merrier smile
Posted By: bsdimp

Re: VENIX Disks - 04/21/17 06:12 PM

The Rainbow Venix disks were feared lost forever. I've managed to read them all and am processing them into the proper image files right now. It was the only true Unix than ran on the Rainbow, and should make a nice addition to MESS'. There's indications there might be source on these, but I think that's just a re-used label. There is a c compiler, so reconstructing sources may not be outside the realm of the possible, at least for some items.

My venerable Rainbow, though, is showing signs of failure. It flakes out after it's been powered on for a few hours. Still trying to figure out why and what my next course of action should be.
Posted By: bsdimp

Re: VENIX Disks - 04/22/17 07:06 PM

So I've pulled together the ROMs and am trying to run mame on my macbook pro. I have a couple of questions. They are rather newbie-ish, so please forgive me.

I can find lots of information on floppy formats. I think I can find one that will work there. I have a bunch of floppies for Venix I'd like to try that are pure physical sector copies. What I'm less sure about is the hard disk format. I have two full disk images from a MFM emulator / reader that's read in my ST-251-1 and a friend's RD51. The emulator is at http://www.pdp8online.com/mfm/ in case you are interested. Should I just use chdman, or something else?

Second, is the serial port supported? Is that what bitbang is?

Thanks!

Warner
Posted By: bsdimp

Re: VENIX Disks - 04/22/17 08:03 PM

BTW, I've tried booting the recent venix boot disks. It's a bit slower than the real hardware, but not terrible.

However, there's some issues, but I'm not sure the root cause. It only detects 128k of RAM, but that may be due to a configuration issue on my part. It shows 128k in setup.

I create a disk with 'chdman createhd -chs 1024,6,16 -c none -o venix-rb.chd', and when venix goes to access it during install, it seems to hang. I haven't formatted it, so that may be part of the issue. The failure mode on real hardware with unformatted drives is an error about not being able to access a specific C H S.

You can find the Venix disks that I'm using at http://people.freebsd.org/~imp/venix86r-2.0.tar.xz. Root password is 'gnomes' if you get farther than I did. I've installed these on a real Rainbow 100B, so I know the images are good. The .flp files are raw images with no headers. vboot.flp and all xfer disks are bootable.

Btw, I'm running this on mac with 'mame64 rainbow -flop1 flp/vboot.img -hard1 venix-rb.chd' on a system that I'd previously gone into setup and saved.

These Venix disks recently surfaced. I've imaged them, installed them on my Rainbow, etc. I'll be blogging the experience and would like to have a section on running this under mame/mess.
Posted By: Bavarese

Re: VENIX Disks - 04/23/17 10:16 AM

Thank you for making this gem available!

I wrote a PM with some answers and a description of the current state.

The Rainbow driver should be restructured next, best before the 100-A ROMs are available.

For now, a recompile cycle is necessary (since all assumptions concerning the 100-A are kept in hand-crafted precompiler macros, which is kind of safe but very ugly).

Hint: i could use some help smile
Last time i tried to use MACHINE_CONFIG_FRAGMENT(.. ) for alternate machine configurations around MAME 0.160, it caused problems after the second machine reset.
Additionally i seemed unable to cover subtle differences in port logic with this approach...
Posted By: bsdimp

Re: VENIX Disks - 04/26/17 02:48 PM

Originally Posted by Bavarese
Thank you for making this gem available!
For now, a recompile cycle is necessary (since all assumptions concerning the 100-A are kept in hand-crafted precompiler macros, which is kind of safe but very ugly).


It looks like I'll have to figure out how to do the recompile cycle myself. It's been, let's just say 'frustrating', the couple of times I've tried in the past.

Warner
Posted By: R. Belmont

Re: VENIX Disks - 04/26/17 02:53 PM

MAME's not actually that hard to build - it's a bit easier on *IX and friends (BSD, Linux, Mac), but it's alright on Windows once you get past the initial setup.

And "make SOURCES=src/mame/drivers/rainbow.cpp REGENIE=1 -jX" will build only the Rainbow and the central core, so things go relatively quickly.
Posted By: bsdimp

Re: VENIX Disks - 04/27/17 12:54 AM

Looks like building is easy on my mac. FreeBSD fails to build. I'll build on my mac. That's something. I have somewhere to hack.

Now if I can just figure out why the 'd' key doesn't cause a 'd' to show up. It isn't limited to the Rainbow emulator. The at386 was suffering form it in the 0.184 image that I was running. About 1 in 20 times the 'd' key produced an effect frown
Posted By: remax

Re: VENIX Disks - 04/27/17 11:45 AM

Are you sure your 'd' key is working ? laugh
Posted By: R. Belmont

Re: VENIX Disks - 04/27/17 12:41 PM

If it's a non-US/non-QWERTY keyboard that might cause problems, but in that case 'd' would never work, not 1 in 20.
Posted By: bsdimp

Re: VENIX Disks - 04/28/17 01:31 AM

Originally Posted by remax
Are you sure your 'd' key is working ? laugh


All the other times I hit the 'd' key, I get 'd'. It's only in MAME running on my MAC that there's issues.... My Mac has a US qwerty keyboard, but the caps-lock is mapped to control. Maybe it's Karabiner, I'll check that out next... (exiting Karabiner fixes the problem)
Posted By: bsdimp

Re: VENIX Disks - 04/28/17 04:39 PM

So why doesn't the -speed actually speed up the floppy access speed? It seems super slow (much slower than real hardware) w/o -speed and just a little slow with a -speed 10 on the command line. Is this a case of a driver that needs to be tuned, or is there something more systemic in MESS that needs to be addressed?

It also looks like Venix is only seeing 10MB of the 48MB drive (ST-251-1) I've setup, even after partitioning with WUTIL, so I'll have to get to the bottom of that. I think I've seen this on semi-real hardware as well.

And when I boot off the hard drive for Venix after installing, I get a watchdog timer triggering and garbage on the screen. I know there's a stack overflow issue for automatic booting, but this was booting off with the 'W' command. Or is that the issue?

The good news is I can boot Venix 2.0 off floppies, do the install and generally mess around with it, though in a restricted environment. It's going much better than I'd thought it might.

I'll try the BSW enhancements to see if that helps or not.
Posted By: Bavarese

Re: Requirements? - 04/28/17 05:44 PM

Quote
So why doesn't the -speed actually speed up the floppy access speed?

Good question. I am open to suggestions. The new floppy code is at least accurate, timing wise (same cannot be said from the WD2010/1010 hard disk controller code i cobbled together).

Quote
And when I boot off the hard drive for Venix after installing, I get a watchdog timer triggering and garbage on the screen. I know there's a stack overflow issue for automatic booting, but this was booting off with the 'W' command. Or is that the issue?

Correct, both 'W' and auto-boot are affected. It is the same bug. A CPU crash (watchdog event) occurs @ the 3rd stage of the boot loader. Unfortunately i cannot find the cause. Also, the third stage pulls tricks i can't fully grasp as a 6502 guy. smile

In short: the Z80 thinks it boots from floppy, when data is piped from hard disk sectors instead. The 808x does something, the WD1010 does something, and somehow too many IRQs fire...so the 808x finally stalls.
The loader binary is hidden in one of the WUTIL.? files of the distribution archive - if someone wants to take a look.
Crazyc?

WUTIL comes with an extended boot loader much more capable than DEC's. Unfortunately, even the latest version (i think it was 3.2) crashes in our emulation. Just like DEC's limited, old one

The 3.0 or 3.1 archive came with Turbo Pascal source. I have it somewhere.
Posted By: Bavarese

Re: Requirements? - 04/29/17 01:31 AM

PREBOOT.ASM and SECBOOT.ASM contain commented assembler source.
One oddity i remember is that at least 1 geometry value (heads) inherited a wrong value (zero) from one of the earlier boot stages...
Source files

Binaries
Posted By: bsdimp

Re: Requirements? - 04/30/17 05:14 PM

Yea, I have that file. I'll have to take a closer look. Sadly, most zip files from that era give me errors like:
x $README.1ST: Unsupported ZIP compression method (imploded)
when I try to decompress them on modern hardware...
Posted By: bsdimp

Re: Requirements? - 04/30/17 06:07 PM

Looking at the source, it looks like it includes the Z80 boot code from the MS-DOS diskette (first two tracks). ZFLIP may well be in play, even though we don't need the floppy code to boot from the hard disk, the boot loader appears to put it in place and the rest of the OS depends on it... executing the wrong code during this because ZFLIP is wonky would definitely cause weird behavior, including stack overflow. 8088 processors really hate 8080/z80 code smile
Posted By: bsdimp

Re: Requirements? - 05/01/17 02:51 PM

In going through my floppy collection, I've found an alternate copy of Windows. The one that's normally available has issues, I'm told, with VAXmate files being mixed in and gumming up the works. These files are different, and on a set of disks that said "Windows 1.03" on them with a letter saying it is OK to upload them to BBSes dated in 1988. So I thought I'd pass them along to see if they are helpful fleshing out the graphics card at all. Since I think they are kosher to redistribute, I've put them up at github at https://github.com/bsdimp/rainbow100.git for all to enjoy. I have no clue how to install them or anything like that.
Posted By: Bavarese

Re: Requirements? - 05/01/17 06:53 PM

Thanks for taking a look. Just for the record, an emulation of the DEC mouse protocol will be needed before we can give Windows 1 a try.

Back in 2012, i compiled some info here. I personally never got a graphics card, nor a DEC mouse - so i can't tell which of the serial ports was occupied.

As these mice were usable together with other workstations, working on them might be of some interest to others.
Posted By: Bavarese

Re: Requirements? - 07/07/17 06:06 PM

Good news: i unblocked the 'auto boot' feature available within SET UP (see latest pull request).

The bad thing: i discovered a weird one-off bug in WUTIL 3.2. It appears that the primary boot loader (located in PREBOOT.LDX) has an unexplained offset of 1 byte.

This is either a bug in a 27+ year old, widely used hard disk tool nobody noticed - or an emulation bug.

PREBOOT.ASM is assembled with a NOP - which is vital, but eaten away by the BIOS (explanation in part 2 below). And the FAR call afterwards does add another +1 offset (call 0000:1001 in disassembly, which results in a botched stack pointer save right after START):

Code
mov [1170],sp    89 26 70 11

is executed instead of
Code
mov CS:[1170],sp    2E 89 26 70 11

(= correct statement)

It is unclear why real machines do not crash. Unfortunately i have no working machine left.

When i add an extra $90 (NOP) byte at the start of PREBOOT.LDX it suddenly works. Hey, it even boots CP/M :-)

So it would be very nice if someone (perhaps a 8086 expert) could give me a pointer in the right direction :-)

Robert or Warner, can you please test my bug fixed / 1 byte longer PREBOOT (complete with Wutil 3.2) on a real machine?
https://www.dropbox.com/s/s5eitbyy409yrzu/MODDED_WUTIL_V3.2.ZIP?dl=0

From listing:
https://www.dropbox.com/s/hjdslxjdv6726gt/PREBOOT.ASM?dl=0

Code
SECBOOT	SEGMENT	AT SECSEG
	ORG	0
	ASSUME	CS:SECBOOT

SBFRST	DB	?

SBSTART	PROC	FAR
	NOP
SBSTART	ENDP

SECBOOT	ENDS

CODE	SEGMENT
	ORG	1000H

	ASSUME	CS:CODE, DS:NOTHING, ES:NOTHING, SS:NOTHING

START:	NOP				;This NOP must be here for ROM boot  [ <--- EATEN AWAY BY BIOS, see code before / at F48C0 ]
	MOV	 WORD PTR CS:SAVESP,SP	;Save SP contents at entry time


Full source for boot loaders:
https://www.dropbox.com/s/mvdjtupnbfb2bsq/WUTIL_3.x_SRC.zip?dl=0

-----------------------------------------------------------------------------------------
From BIOS source:
https://github.com/shattered/retro-bios/blob/master/dec-rainbow100b/8086_DISASSEMBLY_23-022e5-00

Use 'bpset F48C0' to see the far call in action.

Code
seg000:08A0                 in      al, 60h
seg000:08A2                 cmp     al, 90h ; 'É'   ; First byte is $90 (NOP) ?
seg000:08A4                 jnz     short NON_SYSTEM__loc_8CD ;
seg000:08A4                                         ;
seg000:08A6                 mov     cx, 200h        ; 512 bytes
seg000:08A9                 mov     di, 1000h
seg000:08AC
seg000:08AC GET_BYTES__loc_8AC:                     ; CODE XREF: sub_84+82Bj
seg000:08AC                 in      al, 60h         ; WD1010 input port (8 bit data)
seg000:08AE                 stosb
seg000:08AF                 loop    GET_BYTES__loc_8AC ;
seg000:08AF                                         ;
seg000:08B1                 in      al, 67h
seg000:08B3                 mov     ax, 0EE00h
seg000:08B6                 mov     ds, ax
seg000:08B8                 assume ds:nothing
seg000:08B8                 mov     ax, sp
seg000:08BA                 sub     ax, 4
seg000:08BD                 mov     ds:1FF7h, ax
seg000:08C0 call far ptr loc_FFF+2 ; BOOT STRAP FROM HARD DISK   [ translates to 9A 01 10 00 00 ]

Posted By: crazyc

Re: Requirements? - 07/07/17 11:08 PM

I don't get the problem there. The BIOS disassembly shows a call to 0000:1001 and the source for the bootloader has "ORG 1000H" which means it should be loaded at 0000:1000. Since the first instruction of the bootloader is NOP then the CS: override should be at 0000:1001 which is correct. Your description suggests that it's loaded at 0xfff or the cpu is branching to 0x1002.
Posted By: Bavarese

Re: Requirements? - 07/13/17 05:32 PM

It turned out to be a bug in WUTIL 3.2. The boot loader is one byte too short. $90 NOP must be present twice. One byte is discarded by the BIOS, see :08a0.

Now i have Windows 1.0.3 running, and i would like to use a microsoft serial mouse (which seems supported in 1.0.3).

I added

Code
MCFG_DEVICE_MODIFY("rs232_a")
MCFG_SLOT_DEFAULT_OPTION("null_modem")
MCFG_SLOT_OPTION_ADD("microsoft_mouse", MSFT_SERIAL_MOUSE)
MCFG_SLOT_OPTION_ADD("mousesys_mouse", MSYSTEM_SERIAL_MOUSE)


Do i have to add additional code? Guess i have to wire some signals. There aren't that many samples in our repository (the PC JR uses another UART)...

(WineMine ported to Windows 1.x by Nathan Lineback)
https://www.dropbox.com/s/0isjzpfwlbddpaj/MS_Windows_1.0X_1985_SCREENSHOT_WineMine.png?dl=0
Posted By: R. Belmont

Re: Requirements? - 07/13/17 06:29 PM

Rainbow's almost done RS-232 wise, you just need to hook up the transmit from the uPD7201.

Find this:

Code
MCFG_UPD7201_ADD("upd7201", XTAL_2_5MHz, 0, 0, 0, 0)    // 2.5 Mhz from schematics
MCFG_Z80DART_OUT_INT_CB(WRITELINE(rainbow_state, mpsc_irq))


Add these two lines:

Code
MCFG_Z80DART_OUT_TXDA_CB(DEVWRITELINE("rs232_a", rs232_port_device, write_txd))
MCFG_Z80DART_OUT_TXDB_CB(DEVWRITELINE("rs232_b", rs232_port_device, write_txd))


And that will enable the Rainbow to transmit on both RS-232 ports.
Posted By: Edstrom

Re: Requirements? - 07/13/17 07:12 PM

Or you can try the new z80sio where I have added the upd7201 support recently, or did I ask you to do that already? smile

Code
#include "machine/z80sio.h" // instead of z80dart.h


Code
MCFG_UPD7201_ADD("upd7201", XTAL_2_5MHz, 0, 0, 0, 0)    // 2.5 Mhz from schematics
MCFG_Z80SIO_OUT_INT_CB(WRITELINE(rainbow_state, mpsc_irq))
MCFG_Z80SIO_OUT_TXDA_CB(DEVWRITELINE("rs232_a", rs232_port_device, write_txd))
MCFG_Z80SIO_OUT_TXDB_CB(DEVWRITELINE("rs232_b", rs232_port_device, write_txd))
Posted By: R. Belmont

Re: Requirements? - 07/13/17 08:01 PM

The hooks back to the 7201 would need to be changed for the two RS-232 ports too then smile
Posted By: Bavarese

Re: Requirements? - 07/14/17 10:55 AM

DTR and RTS output seem to be controlled entirely by the 808x (with some help by the BIOS). I have no idea how to reconcile that with the Z80DART (or Z80SIO) code. Is it possible the CPU controls these lines independently?

Additionally, the status of the RI, CTS and DSR lines have to be reflected on 808x port 02 ('comm_control_r' in Rainbow.cpp).

Tony Duell's schematics and the 2 stubs we have in RAINBOW.CPP -
Tony Duell's schematics vs. curent code (right)

As always, i could hack my way to success (e.g. patch Windows 1.0.3 to not use the hardware flow control for mouse detection). I better ask and do it 'the MAME way' (darn macros).

Something i can do independently: the serial mouse needs a downgrade to mimic the old MS 2 button mouse protocol ("M" response, no third button, possibly 7 O 1 instead of 7 N 1).

Again, thanks for any hints smile

History would be different if DEC officials had recognized the potential of Windows on their non compatible machine.

GRAPH application on MS Windows 1.0.4 (Rainbow 100 - MESS)
Posted By: Duke

Re: Requirements? - 07/14/17 01:29 PM

Originally Posted by Bavarese
DTR and RTS output seem to be controlled entirely by the 808x (with some help by the BIOS). I have no idea how to reconcile that with the Z80DART (or Z80SIO) code. Is it possible the CPU controls these lines independently?

Additionally, the status of the RI, CTS and DSR lines have to be reflected on 808x port 02 ('comm_control_r' in Rainbow.cpp).

Tony Duell's schematics and the 2 stubs we have in RAINBOW.CPP -
Tony Duell's schematics vs. curent code (right)


Something like this?

https://git.redump.net/mame/tree/src/mame/drivers/cgenie.cpp#n240

Code
READ8_MEMBER( cgenie_state::control_r )
{
	uint8_t data = 0;

	data |= m_cassette->input() > 0 ? 1 : 0;
	data |= m_rs232_rx << 1;
	data |= m_rs232_dcd << 2;

	return data;
}


You just need to save the line state from the rs232 device and then return it in the appropriate location.
Posted By: R. Belmont

Re: Requirements? - 07/14/17 01:42 PM

Windows itself will program the 7201 for 7O1 or whatever format, and I think our serial mouse supports the old protocol because we've used it with PC Windows 1.0.x.
Posted By: Bavarese

Re: Requirements? - 07/16/17 07:25 PM

I have rewritten the Rainbow driver to use Z80SIO instead of Z80DART as well as hardware flow control.

Now at least, the mouse resets (ser_mouse.cpp -> routine: input_rts).

https://www.dropbox.com/s/6ya3qj96f0k6rax/Z80SIO_with_MS_MOUSE_-_Windows_1.x.jpg?dl=0

Then, unexpected bytes appear. Instead of the expected identifier ($4D = "M") i observe $3b (binary 0111011).

Parameters are 7,N,1, 1200 baud (set by Windows at startup for both directions).

Is my code correct?

https://www.dropbox.com/s/so2vyytgkcz8azl/2017%2007%2016%20-%20rainbow.cpp?dl=0

Routines and statements added:

READ8_MEMBER(rainbow_state::comm_control_r)
WRITE8_MEMBER(rainbow_state::comm_control_w)

WRITE_LINE_MEMBER( rainbow_state::rs232_dcd_w )
WRITE_LINE_MEMBER( rainbow_state::rs232_dsr_w )
WRITE_LINE_MEMBER( rainbow_state::rs232_cts_w )
WRITE_LINE_MEMBER( rainbow_state::rs232_ri_w )

MCFG_RS232_DCD_HANDLER(WRITELINE(rainbow_state, rs232_dcd_w))
MCFG_RS232_DSR_HANDLER(WRITELINE(rainbow_state, rs232_dsr_w))
MCFG_RS232_CTS_HANDLER(WRITELINE(rainbow_state, rs232_cts_w))
MCFG_RS232_RI_HANDLER(WRITELINE(rainbow_state, rs232_ri_w))

I can also provide a ready-made CHD with Windows 1.x if somebody wants to test drive.

Thanks for having a look.
Posted By: Edstrom

Re: Requirements? - 07/16/17 10:22 PM

I can't really tell if it is correct for the Rainbow as I don't know that machine but it looks ok.

If you turn on logging in z80sio.cpp by setting some of the LOG bits then you'll see what's going on, I'll suggest you use

Code
#define VERBOSE (LOG_SETUP|LOG_INT|LOG_CMD|LOG_DCD|LOG_CTS|LOG_TX|LOG_RX|LOG_GENERAL)
#define LOG_OUTPUT_FUNC printf


You can remove LOG bits if it gets too cluttered. For instance you will see the baudrate as seen by the 7201 and you will see special commands such as software iacks. The LOG_OUTPUT_FUNC directs the output to your terminal so you can use more, less or grep on the log or just direct it to a file, quite handy compared to the MAME log window

The call to m1_r() on line 2571 is not needed as the 7201 does not have an M1 input, instead it expects to get a software iack.
Posted By: Bavarese

Re: Requirements? - 07/17/17 12:28 PM

Thanks for the nudge in the right direction.

I now see a lot of lines with "Null command" and "CRC_RESET_NULL".
https://www.dropbox.com/s/6ss4f4g1d0mtlhe/Null_command.png?dl=0

Stop bits, length (7), parity (none) seem to be correctly set.

What is totally absent -in the log- are RX and TX baud rates (at least values do not appear in 'update_serial').

Here the code section where i set an external baud rate generator from within Rainbow.cpp (2nd screenshot).

It uses the Com8116 baud rate generator Shattered recommended (#include "machine/com8116.h") -
Code
// PORT 0x06 : Communication bit rates (see page 21 of PC 100 SPEC)
WRITE8_MEMBER(rainbow_state::comm_bitrate_w)
{
	m_dbrg_A->str_w(data & 0x0f);  // PDF is wrong, low nibble is RECEIVE clock (verified in SETUP).
	printf("\n(COMM.) receive bitrate = %d ($%02x)\n", comm_rates[data & 0x0f] , data & 0x0f);

	m_dbrg_A->stt_w( ((data & 0xf0) >> 4) );
	printf("(COMM.) transmit bitrate = %d ($%02x)\n", comm_rates[((data & 0xf0) >> 4)] ,(data & 0xf0) >> 4);
}

// PORT 0x0e : Printer bit rates
WRITE8_MEMBER(rainbow_state::printer_bitrate_w)
{
	m_dbrg_B->str_w(data & 7); // bits 0 - 2
	m_dbrg_B->stt_w(data & 7); // TX and RX rate cannot be programmed independently.
	printf("\n(PRINTER) receive = transmit bitrate: %d ($%02x)", 9600 / ( 1 << (7 - (data & 7))) , data & 7);

	// "bit 3 controls the communications port clock (RxC,TxC). External clock when 1, internal when 0"
	printf(" - CLOCK (0 = internal): %02x", data & 8);
}

Maybe something is missing?

There is also an odd clock bit (not part of the Z80SIO, must be external circuitry) not handled yet (normally zero).
See printer_bitrate_w above.

Log from screenshot (as text):
Code
Z80SIO ":upd7201_new" Channel B : CRC_RESET_NULL
 * :upd7201_new:chb B Reg 02 <- 00 - WR2

void z80sio_channel::control_write(uint8_t)(00) reg 02
Z80SIO ":upd7201_new" Channel B : Interrupt Vector 00

(COMM.) receive bitrate = 1200 ($08)
(COMM.) transmit bitrate = 1800 ($09)

void z80sio_channel::control_write(uint8_t)(02) reg 00
void z80sio_channel::do_sioreg_wr0(uint8_t) :upd7201_new:cha Ch:A : Null command

void z80sio_channel::do_sioreg_wr0_resets(uint8_t) :upd7201_new:cha
Z80SIO ":upd7201_new" Channel A : CRC_RESET_NULL
 * :upd7201_new:cha A Reg 02 <- 10 - WR2

void z80sio_channel::control_write(uint8_t)(10) reg 02
Z80SIO ":upd7201_new" Channel A : Interrupt Vector 10

void z80sio_channel::control_write(uint8_t)(04) reg 00
void z80sio_channel::do_sioreg_wr0(uint8_t) :upd7201_new:cha Ch:A : Null command

void z80sio_channel::do_sioreg_wr0_resets(uint8_t) :upd7201_new:cha
Z80SIO ":upd7201_new" Channel A : CRC_RESET_NULL
 * :upd7201_new:cha A Reg 04 <- 44 - WR4 - Async Clock, Parity and stop bits

void z80sio_channel::control_write(uint8_t)(44) reg 04
Z80SIO ":upd7201_new" Channel A : Parity Enable 0
Z80SIO ":upd7201_new" Channel A : Parity Odd
device_serial_interface::stop_bits_t z80sio_channel::get_stop_bits() :upd7201_ne
w:cha

1 STOP BIT.Z80SIO ":upd7201_new" Channel A : Stop Bits 1
Z80SIO ":upd7201_new" Channel A : Clock Mode 16X
int z80sio_channel::get_rx_word_length() :upd7201_new:cha
Z80 SIO) receive word length: 07device_serial_interface::stop_bits_t z80sio_chan
nel::get_stop_bits() :upd7201_new:cha

1 STOP BIT.void z80sio_channel::update_serial()

(Z80SIO) : data_frame (data_bit_count = 07), parity = 00, stop_bits = 01
void z80sio_channel::control_write(uint8_t)(03) reg 00
void z80sio_channel::do_sioreg_wr0(uint8_t) :upd7201_new:cha Ch:A : Null command

void z80sio_channel::do_sioreg_wr0_resets(uint8_t) :upd7201_new:cha
Z80SIO ":upd7201_new" Channel A : CRC_RESET_NULL
 * :upd7201_new:cha A Reg 03 <- 41 - WR3 - Async Rx setup

void z80sio_channel::control_write(uint8_t)(41) reg 03
Z80SIO ":upd7201_new" Channel A : Receiver Enable 1
Z80SIO ":upd7201_new" Channel A : Auto Enables 0
int z80sio_channel::get_rx_word_length() :upd7201_new:cha
Z80 SIO) receive word length: 07Z80SIO ":upd7201_new" Channel A : Receiver Bits/
Character 7
int z80sio_channel::get_rx_word_length() :upd7201_new:cha
Z80 SIO) receive word length: 07device_serial_interface::stop_bits_t z80sio_chan
nel::get_stop_bits() :upd7201_new:cha

1 STOP BIT.void z80sio_channel::update_serial()

(Z80SIO) : data_frame (data_bit_count = 07), parity = 00, stop_bits = 01
void z80sio_channel::control_write(uint8_t)(05) reg 00
void z80sio_channel::do_sioreg_wr0(uint8_t) :upd7201_new:cha Ch:A : Null command

void z80sio_channel::do_sioreg_wr0_resets(uint8_t) :upd7201_new:cha
Z80SIO ":upd7201_new" Channel A : CRC_RESET_NULL
 * :upd7201_new:cha A Reg 05 <- 28 - WR5 - Async Tx setup

void z80sio_channel::control_write(uint8_t)(28) reg 05
Z80SIO ":upd7201_new" Channel A : Transmitter Enable 1
int z80sio_channel::get_tx_word_length() :upd7201_new:cha
Z80 SIO) transmit word length: 07Z80SIO ":upd7201_new" Channel A : Transmitter B
its/Character 7
Z80SIO ":upd7201_new" Channel A : Send Break 0
Z80SIO ":upd7201_new" Channel A : Request to Send 0
Z80SIO ":upd7201_new" Channel A : Data Terminal Ready 0
int z80sio_channel::get_rx_word_length() :upd7201_new:cha
Z80 SIO) receive word length: 07device_serial_interface::stop_bits_t z80sio_chan
nel::get_stop_bits() :upd7201_new:cha

1 STOP BIT.void z80sio_channel::update_serial()

(Z80SIO) : data_frame (data_bit_count = 07), parity = 00, stop_bits = 01void z80
sio_channel::update_rts()() ":upd7201_new" Channel A
void z80sio_channel::set_dtr(int)(1)
Posted By: Edstrom

Re: Requirements? - 07/17/17 07:17 PM

It looks like the SIO is expecting to get a clock that is 16x the actual bit rate here:

Code
Z80SIO ":upd7201_new" Channel A : Clock Mode 16X


Are you sure the BRG is producing the right bitrate? Also remember that you need two call to, for instance, rxca to shift one bit into the SIO, as only every second is a raising flank, given that you only call it when the clock changes state.
Posted By: bsdimp

Re: Requirements? - 08/03/17 08:17 PM

Do you still need me to test the modded wutil 3.2 on my Rainbow?

Warner
Posted By: Bavarese

Re: Requirements? - 08/04/17 12:24 AM

You've got PM smile
Posted By: bsdimp

Re: Requirements? - 12/07/17 03:53 AM

Just updated my mame sources to the latest after getting a new mac and rebuilt... And the venix image I'd saved away from last time fails to boot with blocked interrupts....

Anybody else using this?
Posted By: bsdimp

Re: Requirements? - 12/07/17 06:44 AM

OK. I just recreated the partition, and have the same issue. Venix installs its own bootblocks, it seems, overwriting the ones I'd installed. I think I have the modded 3.2 wutil, so I'll see if I can make it bootable by booting to that... I hate WUTIL, though, because it only used weird function keys that only exist on the Rainbow, and the keyboard mappings is always opaque enough that it's a hassle. I guess I'll have to see if I can hack it to also support simple letters for its operations as well... Maybe put out a 3.3 with the boot fix and that smile....
Posted By: Bavarese

Re: Requirements? - 12/09/17 11:01 AM

I tried to map the keyboard 1:1 whenever possible (with few exceptions like Alt and Control). As the PC keyboard has less keys, some rarely used function keys were left out.

Click to enlarge
[Linked Image]

The result is debatable, yet a few applications / games rely on key positions and inconsistent assignments create even more hassle IMHO.

Download
keyboard layout

PDF with some quick notes for people who want to test drive the Rainbow-100 driver. A review would be very helpful.
PDF: First steps on the Rainbow-100

Sources for PDF (in OpenOffice and Word6.0/97 format):
https://www.dropbox.com/s/ux62z46f86tvri5/First_steps%20-%20Dec_2017_Bavarese.zip?dl=1

Does the right Alt key generate a distinct key code on US keyboards (like Alt Gr)...?
Posted By: Bavarese

Re: Requirements? - 12/30/17 03:28 PM

Sorry for not responding. It seems there are only about three Rainbow users left smile

Bsdimp wrote

- the venix image I'd saved away from last time fails to boot with blocked interrupts....


Do you have details how this happened? I suspect the hard disk image was not cleanly unmounted. Did the framework crash and leave you with an unsync'ed file system?

Best advice i can give is to "unmount" the hard disk via internal GUI or via the debugger interface (requires '-debug' option) before exit.

A telltale sign is the BIOS starting with defaults (128 K), because of invalid NVRAM content (-> indicates a partially overwritten NVRAM file).

That said, hard disk corruption often goes undetected with the FAT formatted disks i use. Maybe i should give VENIX a try.

- - - - - - - - On another note, i need to find out if the WD1010 controller can do look-ahead (non-consuming) reads of single bytes.

Question: does the patched WUTIL work on a real machine?

- If yes,
my disassembly of the BIOS is correct, and the loader must be 513 bytes long (because 1 NOP is eaten away by the BIOS check)

- if no, the controller can do single (byte wide) reads without incrementing the internal buffer counter (-> unemulated, because docs are a bit fuzzy here)

Currently, the buffer counter is reset after an overflow (>1024 bytes read or written) or after a hard disk controller reset (separate from the WD1010 chip, via an external memory mapped register located within the 808x mem.range).

The 1024 byte wrap around was determined by trial and error. Which is odd - as there is a 2 K chip on the WD1010 boards.
.

EDIT: there is a sector editor built into WUTIL. A comparison of the HOM, BOM and other relevant areas could clarify things. You can't modify sectors, and it is slow on real machines.
Apart from short comments in the Wutil sources, i haven't found a concise description of these special sectors.
Posted By: Bavarese

Re: Requirements? - 01/24/18 03:56 PM

@Bsdimp: you have mail
Posted By: bsdimp

Re: Requirements? - 04/09/18 05:52 AM

Just FYI. I had so much fun with the Venix stuff last year, I started up this repo to try to recreate the Venix sources. I doubt I'll ever get the compiler back, but other things should be easy. https://github.com/bsdimp/venix/ which also has all the Venix 86 disks I could find (both Rainbow and IBM XT). There's also a 8088 disassembler (but it just groks the Venix variants because I'm lame), and the start of a Venix user-mode thing as well, but that's very early days.
Posted By: Bavarese

Re: Requirements? - 04/17/18 12:20 PM

Thanks, you've put up a great online resource there!

Being a relative Unix noob, i can't find a way to partition disks from inside the VENIX boot disk.

Disk 1 never touches the hard disk in MAME, or initializes the WD2010 controller. Weird.

Startup should begin with a file system check, right?

Guess i have to edit 'inittab' (or sth. similar)...?

The only complete documentation i found is the Programmer Reference Manual for the Pro - hardly a good reference for end users. smile


BTW, you should be able to boot from the - supposedly - lost partition after the following source patches (last 2 lines before ENDIF).

Dump the WUTIL version with the 513 byte boot sector (LDX) and use regular v3.2 from the archives then. You'll see the WUTIL boot menu if everything is set up correctly.


Code
892: #ifdef WORKAROUND_RAINBOW_B
893 	uint8_t *rom = memregion("maincpu")->base();
894  ... 
89X rom[0xf4000 + 0x03d8] = 0x00; // - - - - - unblock BIOS auto boot 
89Y rom[0xf4000 + 0x8aa] = 0x01; // - - - - - JMP FAR 0000:1000 (could be a Rom bug)
89Z #endif

Still hope to get things fixed in MAME/MESS - where a speedup of 4 times relative to an original Rainbow is feasible (startup params -nothrottle -frameskip 10).

For the record: a newly introduced UI bug prevents keyboard reassignments on the emulated LK-201 (it definitely worked in 0.186)
https://www.dropbox.com/s/5v5sjcgv49rryhk/UI%20Bug%20mit%200.197%20X.jpg?dl=0
Posted By: bsdimp

Re: Requirements? - 04/17/18 10:34 PM

You should be able to boot vbswx1.flp. It's a copy of the 'recovery' disk that's been enhanced to recognize any winchester drive size. The vxfer*flp disks will work too, but are the simple version and only recognize an RD51 10MB drive (or at least, it assumes it's a RD51, regardless of what it really is).

http://www.vintagecomputer.net/digital/VENIX/VENIX_Install.pdf has basics. The BSW stuff is a little different, but not that different. Mostly, it requests more disks at the end of the process to load the enhancements from BSW. I think that it's decent. I have no power right now, but if it's not so good, I'll walk through things on MESS and post screen shots.

http://www.vintagecomputer.net/browse_thread_record.cfm?id=675&tid=5 has some more details as well, though the xhomer project linked from there seems to be off the air.

I'd love to have a faster MAME/MESS rainbow running as well.

Hmmm, I'll have to run through what I've done in the past... there's a step to create the raw image, wutil it with a venix partition, marking it bootable, then booting venix restore...

../git/mame/mame64 rainbow -flop1 ~/git/venix/dist/rb/vbswx1.flp

gives me a screen that asks if I want to format the Winchester Drive then gives me an error because I don't have a hard dive connected.... I'll try to write more later.

Posted By: bsdimp

Re: Requirements? - 04/18/18 09:29 PM

BTW, I've updated my Venix github thing with (a) a copy of all the VENIX manuals from bitkeeper's (thanks for the pointer). They cover both PRO and Rainbow version of VENIX! And they cover the missing system calls I'd worried about. and (b) I've started a write up for how to install on MAME.... It's still super incomplete. I need to rebuild MAME with the fixes to the boot roms, at the very least since it's not (yet) working...
Posted By: bsdimp

Re: Requirements? - 04/19/18 01:34 AM

The latest git repo mame just built for me. And Venix boots for me now. Woot! However, shortly after it hangs while running fcheck... sometimes with Interrupts off message, other times it just hangs....

I've uploaded the image https://people.freebsd.org/~imp/venix-rd32.chd.xz if anybody wants to look at it.

mame64 rainbow -flop1 ~/mame/rb/flp/vbwsx1.img -hard1 ./venix-rd32.chd -nothrottle -frameskip 10

(both with and without the last args). Looking at the programs, they look good, as far as I can tell....

It seems like it's missing an interrupt, since the program hangs, and I can't ^C out of it, which is typical for a process in 'disk wait' and we'll never exit disk wait if we don't get an interrupt. Plus there's interrupt enable/disable issues. I'll have to find some time to look into that if someone doesn't beat me to it.
Posted By: Bavarese

Re: Requirements? - 04/19/18 12:41 PM

I 'copied a new boot loader' onto the CHD you uploaded - and the system started when i pressed 'W' in the Rainbow boot menu.

After that, things get odd. Observations:

- WUTIL 3.2 doesn't recognize the partition structure / and or identifier. It just shows GAP (for 'empty space').
Can't tell if Wutil was ever tested with BSW.

- MS-DOS 3.1 recognizes 'non MS-DOS partitions on the hard disk' at startup.

Sure the hard disk image has been correctly initialized?


A general problem is that older (DEC) tools are hard coded for 4 heads and a limited set of OEM hard disks, while newer tools rely on badly documented hd.structures (HOM, BOM, DPD, whatever).

I observed earlier that Wutil did not fill in the number of heads value when it should. It put in 0x00 and a divide by zero resulted - when later code tried to determine the cylinder #.


[Analysis of the Fschk crash] - - LOG

A quick look into 'error.log' reveals the last read is from sector number #15.

Sector numbers 1 to 12, then 10, 15, 15 are read (last one twice -> retry...?)

Code tries to write, but doesn't complete all of the necessary steps (set head, drive, sector in WD2010 controller) before 'fschk' runs into the woods.
The write isn't actually done.

I tested my hard disk code routines (hdc_write_sector, do_write() ) mainly on MS-DOS 3.x, so there can be access patterns i haven't covered (or race conditions).

'Interrupts off' (flickering in emulator) usually occurs after IRET (return from interrupt), when the stack is messed up.

You may turn on logging when you set 'log' to 1 in 'mess.ini'.

The ini file can be rebuilt with
>mess -showconfig > mess.ini

---- [EDIT]
@Bsdimp: what is the purpose of 'fcheck'?

@R.Belmont: may i ask if there is any news on the rewrite of WD2010...? smile
Posted By: bsdimp

Re: Requirements? - 04/21/18 02:31 AM

fcheck checks the filesystem to make sure that it's still self-consistent... It should just be reading all the meta-data from the filesystem, but not the data blocks...
Posted By: Bavarese

Re: Requirements? - 07/29/18 09:15 AM

I received several requests on how to set up Windows 1 on the Rainbow-100 B, so let me share some info.

First, it seems that DEC Windows for the Rainbow was never offically endorsed / released and the main SETUP is missing from all archives. The whole thing looks like a hard-wired, runtime version of Windows.

We haven't figured out how to connect a serial mouse (neither with 1.03 nor with the older version floating around). This is consistent with the Rainbow FAQ. There could be a dongle involved.


I believe it was on port #1 (not the crippled serial printer port) and hardware handshake is necessary (-> FDXB mode in SET UP).

The keyboard [cursor keys + Enter] may be used to move the mouse, but that's not really pleasant... smirk


Windows 1.03 -for DEC Rainbow- had the serial Microsoft Mouse hard coded in the main executable (the 2-button version).

The older Windows release 1.02 (or was it 1.01...?) had an unemulated, proprietary 'DEC serial mouse' built-in [basically a reprogrammed Logitech C-7 mouse].

Mouse drivers from older archives are PC-specific and thus useless (dissamblies show Windows *.DRV files poke PC - I/O ranges not valid on the Rainbow).



Here are some hints to get Windows working - somehow

You'll need a hard disk loaded with MS-DOS 3.1x from Suitable Solutions (think so) and the 7220 Color Graphics Expansion (i don't have), as well as >= 128 K RAM (more is better).
The 7220 Graphics Card can be enabled via DIP switches in emulation. You'll have to choose one of the 'side-by-side' configurations in 'video options' (so you'll see 2 screens, one for text, one for graphics).

1) Bsdimp put up a repository of a 'cleaned' version (version 1.03 minus useless *.DRV driver files):
https://github.com/bsdimp/rainbow100/tree/master/decwin

Decompress the files on a DEC hard disk to folder C:\WINDOWS. Hard disk must be enabled before boot.


2) start the game 'pacman.zip' (and quit / F10) ... before you start Windows 1. This is an unresolved initialization bug in our graphics card emulation
Link:
http://oldcomputers.dyndns.org/public/pub/mirror/os2site/sw/dec/rainbow/msdos/games/pacman.zip

Otherwise a blank screen appears with unresponsive controls.

AJR fixed the serial interface (in MAME/MESS >= 0.196) after my Windows experiments - so things might have improved (from an emulation perspective).

I tried to debug the case without success, so i'd be really happy if someone figures out what inhibits the first Windows start (see 2) or how to exactly set up a mouse.

[Bavarese]

P.S.: an updated introductory PDF (-> covers non-obvious steps like the complicated MS-DOS 3.x setup):
Dropbox link: First steps with the DEC Rainbow 100-B (April 2018 edition)
[April 2018 edition]

Windows 1.x + 2.x Apps
http://toastytech.com/guis/win1x2x.html

PC-centric history about Windows 1 (Premiere Edition)
https://winworldpc.com/product/windows-10/final
Posted By: Bavarese

Re: Requirements? - 10/19/18 02:53 PM

Just a quick error report:
the WD2010 based (primary) hard disk has stopped working on the Rainbow between August and October 2018 (today).

To be more specific: git source from August 30th worked and bleeding edge from October 19th 2018 fails ... with a perfectly legit CHD file.

https://www.dropbox.com/s/z637wrycakt46ch/RD53_67MB.7z?dl=1

I assume the CHD format did not change.

An overhaul of WD2010.cpp / .h took place (by Ivan Vangelista)

https://git.redump.net/mame/commit/?id=502a131126d8906bb2e63b3215fcbfc4a91a746b

EDIT: problem fixed (write fault signal was set to 1 permanently)..

Please let me know if there is progress on the rewrite of the WD2010 controller.
Posted By: Bavarese

Re: Requirements? - 10/26/18 12:18 PM

I am glad the mouse is now working in Windows 1.03 (from the Bsdimp repository). Thanks to all!

Unfortunately some of the recent changes (aroundb / on / after August 1st 2018) had a negative side effect on 720 K (PC style) floppies.

Now get 'Illegal seek error' (with impossible track numbers in range 80 - 120 decimal) when i try to access a PC formatted 720 K DD image...

Also, the Winchester test (test #16 on the diagnostic disk) does now crash violently after subtest 6 or 7 - while it worked well in 2015 - when i first made screenshots. smile

Test image (with PC/foreign diskette driver installed):
RD53_67MB.7z


I suspect the floppy / or hard disk handlers in the Rainbow-100 are no longer correctly wired -

Technically, pc_dsk, flopimg or harddriv could be the culprit.

Following changes stick out:

wd_fdc: Convert line handlers to READ/WRITE_LINE_MEMBER (AJR):
https://git.redump.net/mame/commit/?id=07a36d9d661d102da6c6418f1c817f4fd435ecde

wd_fdc: Simplify API. Plus some collateral damage [O. Galibert]:
https://git.redump.net/mame/commit/?id=f1b7a2f97e0a31ab928283732388bec2e6b8f043

Posted By: bsdimp

Re: Requirements? - 02/20/19 06:00 PM

Was going to get back going on Rainbow stuff since life's been too busy for that until lately. Have the issues been sorted out?
Posted By: Bavarese

Re: Requirements? - 02/21/19 09:54 AM

Thanks for your work on VENIX and the updated install guide.

I fixed a few regressions and successfully installed VENIX (BSW) in the meantime.

Wasn't able to correct 'seek errors' with foreign (= PC type) floppies (formerly drives C and D) with source code after August 2018 (?) in DOS 3.10.
Access to 720 K PC floppies used to work before mid 2018 mass changes (macro removal, output handlers). See posts above.

As the cause for the last regression goes over my head, C and D were switched back to standard RX-50 floppies. In theory, one should be able to change the type in 'slot options', reset the machine and be able to use the newly configured hardware...


Other test results:
- no success with the unpatched VENIX disks posted some time ago (WD1010 registers untouched => hard coded for another controller?)
- successfully installed Boston Softworks to WD1010 type hard disk with 0.205 source + following fixes (with newer set of floppies posted on Github)

[Rainbow-100]: write fault must not be set to 1
write fault must not be set to 1 permanently
- remove: m_hdc->in_wf_callback().set_constant(1);

https://git.redump.net/mame/commit/?id=d7538a918e2e750a05e476541996538df69f9923


[Rainbow-100]: document driver state (and remove bloat) (#4410)
...which corrects inverse polarity of the screen blank flag in port 0A
https://git.redump.net/mame/commit/?id=03b79c8dc53cca708f578d810176cb479900443b

@@ -2695,21 +2688,21 @@ WRITE8_MEMBER(rainbow_state::diagnostic_w) // 8088 (port 0A WRITTEN). Fig.4-28 +
m_fdc->reset(); // See formatter description p.197 or 5-13
}

- m_screen_blank = BIT(data, 1);
+ m_screen_blank = BIT(data, 1)? false : true; // inverse logic


[Rainbow-100]: correct palette problems and silence log output (#4373)
...introduces automatic color monitor selection; only really helpful if you plan to use NEC 7220 graphics
https://git.redump.net/mame/commit/?id=2d9895e7bdfe68df8ba9f0f37d254f6a550f3fb3

You'll probably also want to add the unofficial workaround for BIOS auto boot (1) + the 'jump far' workaround to prevent a CPU crash upon boot from winchester (2):
Code
#ifdef WORKAROUND_RAINBOW_B
	uint8_t *rom = memregion("maincpu")->base();
	if (rom[0xf4000 + 0x3ffc] == 0x31) // 100-B (5.01)    0x35 would test for V5.05
	{
		rom[0xf4000 + 0x0303] = 0x00; // disable CRC check
		rom[0xf4000 + 0x135e] = 0x00; // Floppy / RX-50 workaround: in case of Z80 RESPONSE FAILURE ($80 bit set in AL), do not block floppy access.

		rom[0xf4000 + 0x198F] = 0xeb; // cond.JMP to uncond.JMP (disables error message 60...)

		rom[0xf4000 + 0x315D] = 0x00; // AND DL,0 (make sure DL is zero before ROM_Initialize7201)
		rom[0xf4000 + 0x315E] = 0xe2;
		rom[0xf4000 + 0x315F] = 0x02;

rom[0xf4000 + 0x03d8] = 0x00; // unblock BIOS auto boot (1)
rom[0xf4000 + 0x8aa] = 0x01; // JMP FAR 0000:1000 (could be a  BIOS bug or a CPU oddity) (2)
	}
#endif


Also updated my 'first steps' PDF for the Rainbow -
https://www.dropbox.com/s/y5p2yidghdmbpym/First_steps_Rainbow%20100-B_January_2019_edition.pdf?dl=1

Is someone willing to help with the elusive jmp far bug (2) or the PC floppy regressions (720 / 360 K)?
Posted By: bsdimp

Re: Requirements? - 07/03/19 11:00 PM

I just won the following item on ebay. We'll see if this has additional drivers.
DEC Rainbow 100 Corvus Constellation II disks
Posted By: R. Belmont

Re: Requirements? - 07/03/19 11:21 PM

Nice pickup! Hopefully the flat-cable driver is on there in addition to the OmniNet one.
Posted By: Bavarese

Re: Requirements? - 07/05/19 12:04 PM

Wow.

Note that the current Corvus implementation in 'rainbow.cpp' totally relies on info borrowed from TRS-80 groups - and the binary driver for DEC's flavour of CP/M 86/80 V1 from the Maslin archive.

See patch description on page 12 of
Rainbow-100 first steps (January 2019 edition)

The patch could certainly be adapted for CP/M 86-80 V2.0, yet i don't know enough about the internal structures of CP/M laugh

Corvus controller bits were derived from disassembled drivers. I had no documentation. Same goes true for the ClikClok.

First hand info is always better.
Posted By: bsdimp

Re: Requirements? - 07/06/19 03:35 PM

I have the data sheets for chip that's inside the ClikClok (the DS1315), if that would help. There's also the Venix driver for it, which lays bare how it works if you'd like, but it's working, eh? I think it was also derived from the DS1315 datasheet plus looking at the DOS driver, though.
July 4th's master branch is working in with Venix for me, as well as MSDOS. I've not tried CP/M yet.
Thanks for the serial trick: I'll be able to transfer things back and forth more easily now.
I also just purchased a PC1XX-AK for my Rainbow 100A. It allows up to 832k of memory. The board has 8087 silk screened on it, but the 8087 spot wasn't populated (I had high hopes when I read the description).
The disks will be here in a few days. I'll let you know what I find.
Posted By: bsdimp

Re: Requirements? - 07/06/19 07:56 PM

OK, I get errors when I try to use -bitbngr on the command line.

Code
% ../git/mame/mame64 rainbow -hard1 venix-st251.chd -window -comm null_modem -bitbngr socket.127.0.0.1:1234
Error: unknown option: -bitbngr
%


So what am I missing?

-- edit --

the option is now called -bitbanger
Posted By: R. Belmont

Re: Requirements? - 07/06/19 09:42 PM

We have an explicit emulation of the DS1315 in MAME which the Rainbow and the Apple II both use. (On A2 it was called the "No-Slot Clock").
Posted By: bsdimp

Re: Requirements? - 07/07/19 06:18 PM

After a day of working with this I'm impressed.

The emulation gets almost all of the issues with using a 9600 baud connection on a real Rainbow correct (it's easy to overrun it at that rate). I'd hoped I could set the baud rate to 19200 and get 1920cps transfers, but no matter the baud rate I'm maxed out at ~(speedup * 170)cps. Real rainbow hardware has similar performance, at least when transferring to Venix (I max out at around 180-185cps).

You emulate the bad baud rate stuff as well. When Venix is running its default getty at '7' is is using 2400 baud. The default serial rate is 9600 for MAME, so you get garbage characters, exactly like you would when you do this IRL.
I get several interrupts off messages. More than I get on real hardware, but in similar circumstances. I think there's a race or two left in the Venix winnie or ca drivers that we're faithfully emulating.

Venix still has all the annoying issues of being a V7 port coupled with the unforgiving (by modern standards) error paths in the installation.

So color me impressed. I wish there was a way to "improve" on some of these issues, but I can't think of any that don't reduce the fidelity of the emulation. I may implement a deep invisible rx and tx FIFO for the upd7201 though and see if never dropping a character improves the speed, or reveals more bugs. smile
Posted By: Olivier Galibert

Re: Requirements? - 07/07/19 06:42 PM

Yeah, we've been having fun emulating serial at the wire level, with real clocks and stuff. So we're emulating all the annoyances that come with it :-)

Not everything is converted yet, but one day, one day...
Posted By: bsdimp

Re: Requirements? - 10/03/19 11:16 PM

FYI: I've scanned the Corvus Systems manuals today. I've uploaded them to Corvus Manuals.

I've not yet scanned in the diskettes yet. Here's the files that I uploaded. Hope this is helpful.
  • 7100-04929-corvus-systems-omninet-network-station-installation-guide-dec-rainbow-100-Jul83.pdf
  • 7100-05026-corvus-systems-network-station-users-guide-dec-rainbow-oct83.pdf
  • 7100-05089-corvus-systems-system-managers-guide-dec-rainbow-100-Oct83.pdf
  • 7100-05283-corvus-systems-omnidrive-diagnostic-guide-Feb84.pdf
  • 7100-05692-corvus-systems-multiple-server-update-guide-Feb84.pdf
Posted By: R. Belmont

Re: Requirements? - 10/03/19 11:38 PM

Cool!
© 2019 Forums