Page 1 of 13 1 2 3 12 13 >
Topic Options
#101333 - 08/28/15 09:11 AM VME boards
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
I'd like to discuss VME boards here. VME based systems are highly modular and was introduced early 80ies as a standardized continuation of Versabus. At first only 68000 family was supported but over the years many CPU types and i/o boards were adapted and the latest standard even support 64bits aka VME64. I intend to contribute drivers for a few early ones suitable for emulation. If you sit on information or ROMs fitting this description please let me know.

First out is Force Computers CPU-1 for which I have just filed a pull request. Or you can grab it at https://github.com/JoakimLarsson/mame.git branch m0165_fccpu1_3

layout files and instructions are found here: https://drive.google.com/file/d/0B685nj_1DkdueXdLR2N4STd4RWs/view?usp=sharing
_________________________
https://frakaday.blogspot.se/

Top
#101341 - 08/28/15 06:56 PM Re: VME boards [Re: Edstrom]
shattered Offline
Senior Member

Registered: 05/30/12
Posts: 378
Do you have anything on Force SYS68K series? It was apparently OEM'd in Soviet Union and repackaged into a workstation product (skeleton driver -- besta.c)

edit: d'oh, it *is* the sys68k series :-) I strongly suspect that earliest models of Besta used original Force components and later models used redesigned/customized ones.


Edited by shattered (08/28/15 09:33 PM)

Top
#101342 - 08/28/15 07:20 PM Re: VME boards [Re: Edstrom]
R. Belmont Offline

Very Senior Member

Registered: 03/17/01
Posts: 15487
Loc: USA
Force Computers pull request has been applied to trunk.

Top
#101349 - 08/29/15 05:02 AM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
The CPU-1 is the very first SYS68K board and I think I have the first revision too super seeded by the CPU-1B/D described here: http://bitsavers.trailing-edge.com/pdf/forceComputers/1988_Force_VMEbus_Products.pdf.

I'll take a look at the Besta and see if I can merge the two drivers, I didn't know this, thanks for the pointer!

Edit: Yes, Besta seems to follow the address map and specs of the SYS68K/CPU-30 series launched in Q2/1988, I am only puzzled by the SDRAM which sits in the User EPROM area instead of in the designated SRAM area. I believe that Besta should be a clone if there was a CPU-30 driver.


Edited by Edstrom (08/29/15 05:37 AM)
_________________________
https://frakaday.blogspot.se/

Top
#101350 - 08/29/15 07:34 AM Re: VME boards [Re: Edstrom]
shattered Offline
Senior Member

Registered: 05/30/12
Posts: 378
There's a native SysV Unix OS for it, and a Linux port, btw -- https://github.com/shattered/linux-m68k

Plus lots of documentation, in Russian obviously, some in electronic form.

Top
#101351 - 08/29/15 07:52 AM Re: VME boards [Re: shattered]
Just Desserts Offline
Very Senior Member

Registered: 05/23/09
Posts: 1572
By the way, it's nice to see more new MAME developers from Sweden. Hej from Stockholm! smile

Top
#101356 - 08/29/15 04:02 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Great, maybe I just outline a CPU-30 driver then and try to include the features from Besta as a clone, however I like to have some real hardware too, I am a hands on guy smile I put it on the todo list.

Right now I am struggling with a Heurikon hk68/v10 based on 68010, and I got a Mizar 8105 and a Motorola MVME-350.

Tack detsamma JD!
_________________________
https://frakaday.blogspot.se/

Top
#101357 - 08/29/15 04:39 PM Re: VME boards [Re: Edstrom]
shattered Offline
Senior Member

Registered: 05/30/12
Posts: 378
I'll check if any Besta hardware is available for sale or donation (likely the former, though)...

Top
#101371 - 08/30/15 02:42 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
I have just submitted a pull request for a new VME board, you can grab it at https://github.com/JoakimLarsson/mame.git branch hkv10_2

The Heurikon HK68/V10 VME CPU board

Features: - 68010 CPU @ 10 MHz, 128Kb ROM, 1Mb Dual port DRAM, 1 CIO Parallell interface, 2 serial ports,
1 SCSI interface with support for up to 8 devices, A16/A24 VME bus, Optional MMU, DMA, FPU

This is an advanced 68010 based SBC for VME based industrial applications relesed around 1985. The
intended use is in a VME cage together with VME compatible I/O cards and specifically Heurikon own series. This
manual for Herikon UNIX gives a detailed view on a industrial UNIX configuration:

http://bitsavers.informatik.uni-stuttgar...Guide_Apr87.pdf

Mame emulation currently supports:
- CPU
- 128K System ROM
- 1Mb of RAM
- System ROM Terminal interface

Layout files and instructions found here:
https://drive.google.com/file/d/0B685nj_1DkduaURJZVZqUFljTk0/view?usp=sharing
_________________________
https://frakaday.blogspot.se/

Top
#101422 - 09/01/15 09:56 PM Re: VME boards [Re: Edstrom]
Al Kossow Offline
Senior Member

Registered: 01/06/11
Posts: 147
I just uploaded a couple more Heurikon manuals to bitsavers

Top
#101426 - 09/02/15 09:52 AM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Great! I'd love to do the 960 board one day. Thx!
_________________________
https://frakaday.blogspot.se/

Top
#101433 - 09/03/15 07:15 AM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
New VME board added: Mizar VME8105, a simple 68000 based 3U (half height) board with a OS9 bootstrap on.

The emulation includes a serial device that really isn't on the board but being expected to be found by the bootstrap on a serial VME board nearby. The bootstrap also presumably requires a memory board and boot device board. Anyone with experience of booting OS9/68000, please have a look, layout and details is found here:

https://drive.google.com/file/d/0B685nj_1DkduTG53ZEZldzJZMVk/view?usp=sharing

Let me know what you know about booting a full system.
_________________________
https://frakaday.blogspot.se/

Top
#101580 - 09/14/15 10:07 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Since the main UI on vanilla VME boards usually is a RS232 based terminal of some sort I am trying to figure out the way forward here. While I like the idea of diserial.c it seems to drain a lot CPU cycles. I got Average speed 45% for the fccpu1 board wich has three ACIA6850 and a PIT68230.

I can have done something wrong myself admitedly but when I study the code it seems to do a lot of updating of various signals in the RS232/diserial hook up.

For instance in device_serial_interface where the clock drive calls to rcv_edge which calls rcv_callback for every clock cycle, even when the line has no data on it. This is when my fan is working hard despite I am not typing anything on the terminal.

Why not update the signal in an event driven fashion, only when it changes state? I might have missed something fundamental about emulation though, let me know.

I have also looked at:
1) use one of the emulated VTxxx terminals but that would require firmwares
2) build a live socket connection to a native VTxxx terminal emulator or build in a simple telnet/ssh server

Any advice here is appreciated
_________________________
https://frakaday.blogspot.se/

Top
#101582 - 09/15/15 02:23 AM Re: VME boards [Re: Edstrom]
R. Belmont Offline

Very Senior Member

Registered: 03/17/01
Posts: 15487
Loc: USA
If you have an rs232 connection, you can redirect the serial out to a TCP socket instead of the built-in terminal.

Any serial implementation is going to have a fairly decent CPU load because of timing, although 3 of them shouldn't slow down emulation unless you're on a really dire machine. Any half-recent i5/i7 should handle that fine.

Top
#101628 - 09/18/15 09:08 PM Re: VME boards [Re: Edstrom]
shattered Offline
Senior Member

Registered: 05/30/12
Posts: 378
I've borrowed Force ISCSI-1 hardware manual and going to scan it soon, guess that bitsavers would be interested in that?

Top
#101630 - 09/18/15 09:17 PM Re: VME boards [Re: Edstrom]
Lord Nightmare Offline
Senior Member

Registered: 03/16/06
Posts: 972
Loc: PA, USA
Yes.

Scan it at around 300dpi greyscale (600dpi for schematics or high-res line art), I think Al can postprocess it to bilevel using imagemagick or something similar.

Al?
_________________________
"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"

Top
#101631 - 09/18/15 10:41 PM Re: VME boards [Re: Edstrom]
Al Kossow Offline
Senior Member

Registered: 01/06/11
Posts: 147
that's ok. do the text at 600 so I don't have to interpolate from 300, and save it with lossless compression (NO JPEG!)

Top
#101637 - 09/19/15 07:10 AM Re: VME boards [Re: Edstrom]
shattered Offline
Senior Member

Registered: 05/30/12
Posts: 378
OK, I can do that.

Do you accept text files into the archive? There are quite a few, for the Besta itself and others.

Top
#101649 - 09/19/15 09:12 PM Re: VME boards [Re: shattered]
Al Kossow Offline
Senior Member

Registered: 01/06/11
Posts: 147
sure. just need a pointer to what you'd like to archive. directory and file naming to match the bitsavers style is helpful

Top
#101658 - 09/20/15 09:25 AM Re: VME boards [Re: Edstrom]
shattered Offline
Senior Member

Registered: 05/30/12
Posts: 378
There are also quite a few scans made by others, often from sources that are no longer available -- would you accept those as well? These are often in djvu format. F.e. the manual that I used to write ie15.c driver is: https://docs.google.com/file/d/0B55cuwBw5HR-MHdocUZISVVlQW8/edit?usp=sharing

Top
#101693 - 09/21/15 11:27 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
I have filed a new pull request for a MVME-350 driver, which is a QIC-02 tape controller board. Info how to use is available here:

https://drive.google.com/file/d/0B685nj_1DkduVFpYT3FVZmtKaGc/view?usp=sharing

However, a lot is still to be done and for that an OS with driver is needed and a CPU board driver, for example for a MVME-131 CPU-board. I have neither at the moment so if anyone has info or a spare to lend/donate I'd be happy to help going forward here.

Also any info on VersaDOS and/or Motorola System V Unix is also welcome
_________________________
https://frakaday.blogspot.se/

Top
#101698 - 09/22/15 03:49 PM Re: VME boards [Re: Edstrom]
R. Belmont Offline

Very Senior Member

Registered: 03/17/01
Posts: 15487
Loc: USA
Trying to get my head around things here: this is a VME peripheral board, rather than a host, right? We need to set up a VME bus/slot structure like we have for ISA and such before too much more goes on.

Top
#101699 - 09/22/15 04:42 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Yes, I have started to define the VME bus but needed a peripheral to interact with. I now have both this one and the Mizar board where I faked the SIo board, but could need some directions to make it right. Should I open a pull request with the VME interface and you direct me or do you want to do it yourself?
_________________________
https://frakaday.blogspot.se/

Top
#101700 - 09/22/15 06:50 PM Re: VME boards [Re: Edstrom]
R. Belmont Offline

Very Senior Member

Registered: 03/17/01
Posts: 15487
Loc: USA
I don't know much about VME, but I'm familiar with the bus/slot system (I implemented the Apple II and Mac NuBus buses). So you can either open a pull request with the interface and we can discuss it there, or post it someplace and discuss it here, whichever is more comfortable for you.

Top
#101702 - 09/22/15 10:03 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Some 25+ years ago I was the FAE/Sales engineer for the local distributor of some brands of VME boards here, so I had some training in the VME bus at Force in Munich for instance but I can't claim I am an expert anymore but to some degree I know the bus quite well. Not the MESS bus/slot system however.

VME is basically a multi CPU/Master capable bus with Interrupt/DMA support and priority levels etc and there can only be one Bus Controller (which can also can be master).

The special case here, I believe, is that a VME CPU board can be a Bus Controller in its first instance but not in the second and beyond. Is it possible for a CPU board to instantiate itself? Otherwise we can just derive a base board to be the controller instance and another to be the slot device, let me know what you think.

Some random characteristics of VME boards from top of my head:
The controller provides the Bus clock, the arbiter and also monitors bus collisions and such. The Bus master is the board that currently got the bus from the Bus controller. The slave is getting tasks assigned and will usually generate an interrupt when it is done or it needs to be polled. A bus interrupt can target zero or more boards, usually one.

I have not coded so much yet of the VME driver so I think I just open a branch on my fork and work there until we got something that you are comfortable with, I'll post it here when I have something.
_________________________
https://frakaday.blogspot.se/

Top
#102415 - 11/04/15 10:00 AM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Regarding the emulation of bus timing as mentioned in the shout box recently, where intelligent carts with fast microcontrollers etc insert data into running systems, I have the opposite need when emulating the 68K DTACK.
In a single CPU system it can mainly be ignored but in a VME system there is an arbiter than can postpone a request over the bus infintelly by not granting the bus request until the bus is clear, so then the asynchrounous nature of the 68K upto 68030 is more important.

Any suggestions how this can be handled in MAME?

Will it just work if the read/write handler hangs on the arbiter until the bus request finishes? What about eating clock cycles?
_________________________
https://frakaday.blogspot.se/

Top
#102418 - 11/04/15 01:21 PM Re: VME boards [Re: Edstrom]
R. Belmont Offline

Very Senior Member

Registered: 03/17/01
Posts: 15487
Loc: USA
Unfortunately that isn't possible right now; we need a cycle-by-cycle 68k core that can break out of the read/write and let the scheduler run until the read/write is ready. This is also a pain point for certain things in the Mac driver (Apple used a PAL that allows MOVEing 2 or 4 bytes at a time from the 8-bit-wide SCSI chip; it doesn't tick DTACK until all the bytes are ready from the SCSI bus).

Right now you can either make it so the transaction magically happens immediately, or if that's not possible you can wait on those features until the new core is ready.

Top
#102419 - 11/04/15 02:05 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Ok, I just postpone DMA transfers and other multimaster capabilities until the core is ready for this and do the other accesses magical, as if they were local.


Edited by Edstrom (11/04/15 02:05 PM)
_________________________
https://frakaday.blogspot.se/

Top
#102423 - 11/04/15 03:29 PM Re: VME boards [Re: Edstrom]
Al Kossow Offline
Senior Member

Registered: 01/06/11
Posts: 147
Two revs of the VME spec are on bitsavers under motorola/VME
I should dig around and try to find the extended version of the spec that added 32 bit bus support.

In the very early days, there was a separate bus controller board that handled the arbitration, that was integrated onto the CPU board around the 68020 timeframe.

I know I had the manual for the moto 131, but I haven't seen it in 20+ years. I'm going through storage right now, maybe it will turn up.

Top
#102424 - 11/04/15 05:03 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Makes sense, the arbiter was probably a pain to implement with pure TTL prior programmable logics
_________________________
https://frakaday.blogspot.se/

Top
#102681 - 11/20/15 10:53 AM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Just a small update on my work on the VME bus. I have used the Nubus and ISA bus drivers as role models and tried to make a top down design based on those but there has been too many bus specifics in those drivers that are irrelevant for the VME bus. So I am doing a revamp of the whole thing and starting from scratch with a bottom up design based on my understandings so far.

The direction I have is to model the VME adress spaces (A16, A24, A32 and A64) independently of the address space of the CPU board and map slot devices into those. This is not nearly enough considering the Address Modifiers (AM) but it is a start. The AM allows to differentiate addresses based on access type like program vs data vs I/O fetches and Non-Privileged vs Supervisory and many more. I guess I have to create a separate address space for each since thay can overlap but I will start with a single fixed one and hope for the best.

I will also consider to use the Besta driver as main candidate since there seems to be a full set of software there to use, adding the SCSI-1 board as the first VME slave board. I am also working on a template VME driver and VME slave board, I may submit those too without include them in the build.
_________________________
https://frakaday.blogspot.se/

Top
#102720 - 11/23/15 12:59 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Is it possible to have separate handlers for 8, 16, 32 and 64 bit accesses in the *same* address space. It seems that the memory system will use the first-fit rather than the best-fit, is this correct?

I'd like to trigger VME bus in 4 different addresspaces (A16, A24, A32 and A64) with four different data widths (D8, D16, D32 and D64).

Even an 8 bit CPU can actually trigger any of these through the VME bus device, but usually a 68K like CPU.


Edited by Edstrom (11/23/15 01:00 PM)
_________________________
https://frakaday.blogspot.se/

Top
#102721 - 11/23/15 01:18 PM Re: VME boards [Re: Edstrom]
R. Belmont Offline

Very Senior Member

Registered: 03/17/01
Posts: 15487
Loc: USA
Of course you can. Quoting the next.cpp driver:

Code:
static ADDRESS_MAP_START( next_mem, AS_PROGRAM, 32, next_state )
	AM_RANGE(0x00000000, 0x0001ffff) AM_ROM AM_REGION("user1", 0)
	AM_RANGE(0x01000000, 0x0101ffff) AM_ROM AM_REGION("user1", 0)
	AM_RANGE(0x02000000, 0x020001ff) AM_MIRROR(0x300200) AM_READWRITE(dma_ctrl_r, dma_ctrl_w)
	AM_RANGE(0x02004000, 0x020041ff) AM_MIRROR(0x300200) AM_READWRITE(dma_regs_r, dma_regs_w)
	AM_RANGE(0x02006000, 0x0200600f) AM_MIRROR(0x300000) AM_DEVICE8("net", mb8795_device, map, 0xffffffff)


Notice the 32-bit 68030/040 address space has both regular 32-bit handlers and an 8-bit wide Ethernet device. It's not a problem having handlers of multiple widths in one address space.

The 0xffffffff on the 8-bit device is a byte lane mask - in this case, they spent the extra gates so the 8-bit device appears at consecutive byte addresses in the 32-bit address space, but having the 8-bit device appear every 4th byte (in which case the mask would likely be 0x000000ff) is a cheaper, and therefore more common, scenario.

If you mean multiple width handlers at the same *address*, yes, that will blow up in your face.

Top
#102724 - 11/23/15 02:56 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Exactly, the latter has blown up in my face, at least a bit.

So, if I define just one handler for the max width to handle all access types, say a handler for D16 word access at a specific memory range and the CPU accesses it by byte I find that the handler still get a word access.

I want to find out the 'mask' used for that word access to know if it is the even or odd byte that is accessed. Also for D32 of course.

I don't want to map the slot devices in the maincpu address space but in the VME bus adress spaces since the local addresses can differ from the global bus addresses. This makes it difficult for the VME device read/write handler since there is no information about the width. See page 2-12 in the VME bus specification

It is quite common to strap identical slave slot devices to map to different VME adresses OR, a little less common, to different bits on the same VME adress. The latter allows for reading multiple I/O boards in the same VME bus cycle. So even if I leave this special use cases for the future I'd like to prepare the design for it, if possible.
_________________________
https://frakaday.blogspot.se/

Top
#102725 - 11/23/15 03:28 PM Re: VME boards [Re: Edstrom]
R. Belmont Offline

Very Senior Member

Registered: 03/17/01
Posts: 15487
Loc: USA
All read/write handlers larger than 8 bits have a mem_mask parameter that indicates the active bus lane(s).

So a 16-bit read to a READ32 handler will be passed a mem_mask of either 0xffff0000 or 0x0000ffff.

Code:
#define DECLARE_WRITE64_MEMBER(name)    void   name(ATTR_UNUSED address_space &space, ATTR_UNUSED offs_t offset, 
ATTR_UNUSED UINT64 data, ATTR_UNUSED UINT64 mem_mask = U64(0xffffffffffffffff))


Using a separate address space for the bus is fine; that's how we handle the ISA-on-68000 situation that pops up in a few machines we've emulated.

Multiple cards responding to the same read/write is a harder problem, short of actually just passing all reads/writes to all cards (which is obviously not optimal). Olivier, any ideas?


Edited by R. Belmont (11/23/15 03:32 PM)

Top
#102726 - 11/23/15 03:49 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Great info, thanks!
I tried do decode all the finer points in the ISA bus implementation but got lost, too much new design patterns to take in I guess and also spread over too many files so I found myself page swapping more than reading code in the end!

smile
_________________________
https://frakaday.blogspot.se/

Top
#102748 - 11/24/15 05:36 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Why is A24 an invalid address width? It has special meaning in VME. Should I add it?
_________________________
https://frakaday.blogspot.se/

Top
#102749 - 11/24/15 06:09 PM Re: VME boards [Re: Edstrom]
Al Kossow Offline
Senior Member

Registered: 01/06/11
Posts: 147
Originally Posted By Edstrom
Why is A24 an invalid address width? It has special meaning in VME. Should I add it?


The 68000 only supported 24 bits of address. 68012 (made for HP) had 25 bits. 68020 and beyond were 32 bits.

Top
#102750 - 11/24/15 06:12 PM Re: VME boards [Re: Al Kossow]
Al Kossow Offline
Senior Member

Registered: 01/06/11
Posts: 147
Originally Posted By Al Kossow
Originally Posted By Edstrom
Why is A24 an invalid address width? It has special meaning in VME. Should I add it?


The 68000 only supported 24 bits of address. 68012 (made for HP) had 25 bits. 68020 and beyond were 32 bits.


checking the spec

Option A24 specifies that all addresses generated by the MASTER or decoded by
the SLAVE will be restricted to no more than 23 bi ts. Option A32 selection
extends the address range to 31 bits. The address modifier lines indicate to
SLAVES whether the address is 15, 23, or 31 bits. Option A32 also requires an
expanded bus system.

Top
#102751 - 11/24/15 06:24 PM Re: VME boards [Re: Al Kossow]
Lord Nightmare Offline
Senior Member

Registered: 03/16/06
Posts: 972
Loc: PA, USA
Wasn't there also a '68032' which was a 68000-with-all-32-address-pins? I don't know what it was used in nor how many actual package pins it had...

LN
_________________________
"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"

Top
#102753 - 11/24/15 07:01 PM Re: VME boards [Re: Edstrom]
R. Belmont Offline

Very Senior Member

Registered: 03/17/01
Posts: 15487
Loc: USA
The 68000 core inside the CD-i's 68070 has all 32 address bits valid. I don't know of any A32 680000s other than that.

Top
#102754 - 11/24/15 07:05 PM Re: VME boards [Re: Edstrom]
R. Belmont Offline

Very Senior Member

Registered: 03/17/01
Posts: 15487
Loc: USA
Regarding A24, it's important to note that the 68000 doesn't have a physical A0 line. There are A23-A1 and then two signals indicating which byte lane(s) are valid, so the address space is technically 0x800000 16-bit words rather than 0x1000000 (24^1) 8-bit bytes.

Top
#102755 - 11/24/15 07:34 PM Re: VME boards [Re: Edstrom]
Lord Nightmare Offline
Senior Member

Registered: 03/16/06
Posts: 972
Loc: PA, USA
Given I can't find any pictures of the mc68032, I'm guessing it was either mythical to begin with, or it was a prospective product Motorola planned to offer but never ended up releasing it.

EDIT: AHA! It WAS a real product, but it is called mc68012 and is mc68010 derived! It is 84-pin PGA only. See http://www.cpu-world.com/CPUs/68012/

LN


Edited by Lord Nightmare (11/24/15 07:36 PM)
_________________________
"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"

Top
#102756 - 11/24/15 08:28 PM Re: VME boards [Re: Lord Nightmare]
Al Kossow Offline
Senior Member

Registered: 01/06/11
Posts: 147
Originally Posted By Lord Nightmare
It is 84-pin PGA only.
Originally Posted By Lord Nightmare
Given I can't find any pictures of the mc68032, I'm guessing it was either mythical to begin with, or it was a prospective product Motorola planned to offer but never ended up releasing it.

EDIT: AHA! It WAS a real product, but it is called mc68012 and is mc68010 derived! It is 84-pin PGA only. See http://www.cpu-world.com/CPUs/68012/

LN


from the data sheet

The MC68012 is an expanded address
range version of the M C68010 with the additional address pins A24-A29 and A31. A30 is not included
due to packaging restrictions.

I mis-remembered the number of address bits.

Top
#102757 - 11/24/15 08:30 PM Re: VME boards [Re: Al Kossow]
Al Kossow Offline
Senior Member

Registered: 01/06/11
Posts: 147
Originally Posted By Al Kossow

I mis-remembered the number of address bits.


And the only place that I ever saw them used was the Unix upgrade option for the HP 9836. I didn't know about their use in the FX/8

Top
#102758 - 11/24/15 08:53 PM Re: VME boards [Re: R. Belmont]
Olivier Galibert Offline
Senior Member

Registered: 06/02/01
Posts: 360
Loc: somewhere else entirely
Originally Posted By R. Belmont
Regarding A24, it's important to note that the 68000 doesn't have a physical A0 line. There are A23-A1 and then two signals indicating which byte lane(s) are valid, so the address space is technically 0x800000 16-bit words rather than 0x1000000 (24^1) 8-bit bytes.


Interestingly, the address output buffer (the register that's routed to the address pins) has all 32 bits, and there are 24 address pads (die positions the pins are soldered to), a1-a23 and a31. The a31 pad has no pin soldered to it though.

OG.

Top
#102759 - 11/24/15 10:38 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Well in VME the A1-A23 is called A24 adressing and there is no A0. The 68000 just happens to be the role model for the VME bus but there are plenty of other CPU architectures using it and still have to implement A24! smile There are other lanes used to pick up what byte that is transfered for example for byte transfers in A32 mode.

Another interesting detail about VME A24 mode is that it is the maximum addressable memory area that only requires the P1 connector. For either A32 and/or D32 transfers the second connector P2 is required and there is a bunch of rules how boards can be combined with only P1 or both connectors.

Maybe there is a simple workaround for A24? I am trying to set up one address space per addressing mode A16, A24, A32 and A64. In theory there are 256 different Address Modifiers (AM) which could be mapped to one address space each but I will ignore that now and assume people set up systems based on one or more of the above 4 systems. The AM:s will only be emulated to verify that both the master and slave device agrees on the transfer type.

I think I start with A16 with D8 and D16 transfers until you in the core team decides on the A24 thing.

I would also appreciate advice on how to define the four address spaces, I was thinking just to use AS_0 to AS_3 in the VME device I am creating and map accesses through the read and write handlers from the local AS_PROGRAM address space(s) of the board(s)? Will they not collide internally as the VME device itself is owned by the CPU board in SLOT 0?

The plan is to let the VME device be a slot device and access the other boards through plain slot mapping to one of the four address spaces described above. Some sub-master boards has dual ported RAM as interface to the VME bus and subsequently their own address maps.


Edited by Edstrom (11/24/15 10:41 PM)
_________________________
https://frakaday.blogspot.se/

Top
#102760 - 11/25/15 02:14 AM Re: VME boards [Re: Edstrom]
R. Belmont Offline

Very Senior Member

Registered: 03/17/01
Posts: 15487
Loc: USA
I don't quite understand "decides on the A24 thing". It's totally possible to make address spaces with 24 address bits right now; the 68000, 65816, and several other 16-bit CPUs have one.

Top
#102765 - 11/25/15 08:06 AM Re: VME boards [Re: Edstrom]
Olivier Galibert Offline
Senior Member

Registered: 06/02/01
Posts: 360
Loc: somewhere else entirely
Originally Posted By Edstrom
JThe direction I have is to model the VME adress spaces (A16, A24, A32 and A64) independently of the address space of the CPU board and map slot devices into those.


That sounds like a bad idea actually.

Can you describe what happens when the cpu does an access? What makes the bus decide it's for him, what actually goes on the bus, what the devices see, what they do?

OG.

Top
#102766 - 11/25/15 11:56 AM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
@RB: ok, maybe I am on th wrong path here. I was referring to the address_space::allocate function that throws up at me here
Code:
throw emu_fatalerror("Invalid width %d specified for address_space::allocate", config.data_width());
when trying to create a 24 bit address space. Maybe this is not needed, see below.

@OG: I just realized that I must have dreamt up some features that I have seen and remembered as VME features but they were really special backplanes that for example aggregated four 8 bit I/O boards to allow D32 reads of data from 4 boards in a single cycle. Reading "Observation 2.16" in the spec I know that it is not possible with the VME alone.

This makes it a bit simpler and if I also combine the A16,A24, A32 and A64 into a single address space with only a mask for each I could use the AS_DATA, or what do you suggest?

The reason I want a separate address space is that each master is accessing the bus through a window in the local address space. For example this Force board (see http://bitsavers.informatik.uni-stuttgar...anual_Feb92.pdf)

Code:
Board             A16 - end          A24 - end          A32 - end
----------------------------------------------------------------------
Force  D08-16 FCFFOOOO-FCFFFFFF  FCOOOOOO-FCFEFFFF    
CPU-40 D08-32 FBFFOOOO-FBFFFFFF  FBOOOOOO-FBFEFFFF  01000000-F9FF FFFF


Compare it to this Heurikon board (See http://bitsavers.informatik.uni-stuttgar...anual_Jun91.pdf )

Code:
Board                A16 - end          A24 - end          A32 - end
----------------------------------------------------------------------
Heurikon  D08-16 00C00000-00C0FFFF  01000000-01FFFFFF      
HK68_V3D  D08-32                                       04000000-FFFFFFFF


You can see that the windows for A16 and A24 are complete while the A32 is crippled in order to map local devices. You can also see that the A16 and A24 windows are on different locations in the memory maps. Now if we also add the slave complexity to this it is quite possible that a VME slave board installs in the lower region of the A32 range and would collide with the local devices unless separated.

The master board (any SLOT) requests the bus. The bus arbiter on the controller board in SLOT 0 will grant the bus to the requesting master if there is noone else with higher, or upstream daisy chained with the equal, priority using the bus. The master puts the addresses on the bus together with one of the 8 bit address modifiers (A16, A24, A32, A16-priveleged, A24-user-defined and so forth). Once the adresses are on the bus all boards will compare the adress modifiers and the adresses and respond if they are matching. The slave check what type of transfer is requested on the DS0, DS1 and present the data on the appropriate data lines.

I don't intend to implement the arbiter for now becuase it doesn't makes sense with the non preemptive scheduling model used in MAME currently, so all accesses will be immediatelly granted and fully executed in turn.

EDIT: of course the master board requests the bus *before* it puts the adress there...


Edited by Edstrom (11/25/15 01:10 PM)
_________________________
https://frakaday.blogspot.se/

Top
#102767 - 11/25/15 12:57 PM Re: VME boards [Re: Edstrom]
R. Belmont Offline

Very Senior Member

Registered: 03/17/01
Posts: 15487
Loc: USA
That's D24, not A24. Note the "config.data_width()". We support an arbitrary number of address bits, but data bits must be 8/16/32/64.


Edited by R. Belmont (11/25/15 12:58 PM)

Top
#102769 - 11/25/15 02:58 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Ah, good news, I am sorry but I did mix up some arguments to the address_space_config struct. It makes sense now, no need for core team to do anything here, I just need to understand what I am doing better.

The VME64 standard introduces some new concepts such as the A40 adressing also available for single connector boards by combining the A24 (A1-A23) and D16 (D0-D15) lines where the latter are multiplexed with A24-A39 addresslines. Life is never simple... there is also an optional Configuration ROM capability defined. I think I leave the VME64 extension for later too.

I am still curious if the use of an extra addresspace to map the VME boards makes sense. In theory the Address modifiers adds and extra 8 address bits makin it possible to address 2^40 bytes of data also in a VME32 system. So maybe I can just use that approach and map the whole thing into a A40 address space in AS_PROGRAM?
_________________________
https://frakaday.blogspot.se/

Top
#102851 - 11/30/15 06:52 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298

Ok, after some tinkering with the memory system I have come up with the following implementation plan for VME, just tell me it is plain stupid or I will just try it out. smile

Code:
/*                                                                                                                                                                
 * Implementation notes                                                                                                                                           
 *                                                                                                                                                                
 * 1) VME address space is allocated as an extension of AS_PROGRAM adress space of the                                                                            
 *    controller board in SLOT 0                                                                                                                                  
 *                                                                                                                                                                
 * 2) An adressmodifier keeps track of the offset of each entry and type of access and                                                                            
 *    is determined by a bank tag, eg "vme16_priv", "vme24" etc, set by the card device when                                                                      
 *    registering itself with the VME device.                                                                                                                     
 *                                                                                                                                                                
 * 3) Overlapping areas between VME and local adress space is implemented                                                                                         
 *    as banks by the VME device, automatically by mapping in the appropriate bank based on                                                                       
 *    the adressmodifier.                                                                                                                                         
 */
_________________________
https://frakaday.blogspot.se/

Top
#102855 - 12/01/15 10:07 AM Re: VME boards [Re: Edstrom]
Olivier Galibert Offline
Senior Member

Registered: 06/02/01
Posts: 360
Loc: somewhere else entirely
It's suboptimal. I can't right now but I'll try to tell you about a better design tonight.

Top
#102865 - 12/02/15 12:18 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Thanks, I just need a conceptual direction, let me know and I am on it.
_________________________
https://frakaday.blogspot.se/

Top
#102905 - 12/06/15 11:37 AM Re: VME boards [Re: Edstrom]
Olivier Galibert Offline
Senior Member

Registered: 06/02/01
Posts: 360
Loc: somewhere else entirely
Ok, so the fundamental idea is simple: Going through a memory space is expensive, so you don't want to go through two if you can avoid it. OTOH, modifying a memory map is expensive too (even if I hope to reduce that one day), so you don't want to change it too often either.

In the case of laying out devices in memory, it's usually done only once or twice (firmware, os) in a session's life, so the best way is, I think, directly modifying the main cpu memory map.

You can see an example of that point of view in the new pci stuff (pci.h/pci.cpp and derivatives). Each pci device publishes five address maps (four that go in the main cpu's memory, one for configuration). The root device (and bridge devices) takes all these maps and install then in the appropriate address space with the correct offset and limits.

See pci_device::map_device, pci_bridge_device::map_device and pci_host_device::regenerate_mapping to see how it can be done.

OG.

Top
#102908 - 12/06/15 07:59 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Got it, I have an idea how to implement the address modifier thing with only one address space that I will try out. It will not support all the corner cases but I'll make sure to check for those and and insert proper warnings when seen.

I figure emulation performance is mostly an issue for op code fetches and intensive data handling which ralrely occured over the VME bus, nothing stops a poor system design in that respect. However there are support for DMA reads which is used reading data buffers from disk/tape controller boards etc but it was quite slow in reality too.
_________________________
https://frakaday.blogspot.se/

Top
#104989 - 04/07/16 10:38 PM Re: VME boards [Re: shattered]
shattered Offline
Senior Member

Registered: 05/30/12
Posts: 378
Originally Posted By shattered
I've borrowed Force ISCSI-1 hardware manual and going to scan it soon, guess that bitsavers would be interested in that?


Better late than never, I guess...

https://drive.google.com/file/d/0B8vr5xq7JIHPaUdFVnhfdGNzRmc/view?usp=drivesdk

Datasheets for 68153 BIM, 68230 PIT, 68450 DMAC, NCR 5386S, NCR 8310, and WD1772 are included into the document binder.

Top
#104991 - 04/08/16 01:01 AM Re: VME boards [Re: Edstrom]
Lord Nightmare Offline
Senior Member

Registered: 03/16/06
Posts: 972
Loc: PA, USA
Can you scan the datasheets as well? or are they at the end of that pdf you posted?
_________________________
"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"

Top
#104994 - 04/08/16 07:34 AM Re: VME boards [Re: Edstrom]
shattered Offline
Senior Member

Registered: 05/30/12
Posts: 378
They're in the middle of it.

Top
#105005 - 04/08/16 11:36 AM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
I am working on the Motorola MVME147 right now as I got hold of a ROM set. It has support for the MVME350 tape controller that I have already dumped so in theory I can put together everything and boot from tape over the VME bus when I am done.

I could need some help making the outline of the VME slot device, I have not figured out the best way of doing that yet, it always stumbles on my top down view on MAME, I need more understanding of the bottom part, by time or someone contribute a design, I can implement though. Once established I can populate all the boards with it.

Is there a ROM dump of the ISCSI-1 somewhere?
_________________________
https://frakaday.blogspot.se/

Top
#105018 - 04/08/16 01:20 PM Re: VME boards [Re: Edstrom]
R. Belmont Offline

Very Senior Member

Registered: 03/17/01
Posts: 15487
Loc: USA
Not that I'm aware of, unfortunately.

Top
#105036 - 04/08/16 09:07 PM Re: VME boards [Re: Edstrom]
shattered Offline
Senior Member

Registered: 05/30/12
Posts: 378
Yes, there is one, but it could be from a modded board. PM sent.

Top
#105050 - 04/09/16 05:18 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Finally I got a prompt

but there are some wierd things going on with the serial emulation.

This ROM actually sets up 1 stop bit just like the default "terminal" requires but only works when I patched the z80scc.cpp to always use 2 stop bits, something I knew worked with the hk68v10 driver... and also the input from the terminal doesn't fully work so I need to dig into the diserial details before solving each of the errors on the screen. Progress non the less! smile


Edited by Edstrom (04/09/16 05:21 PM)
_________________________
https://frakaday.blogspot.se/

Top
#105613 - 05/17/16 11:07 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
I found the bugs finally, it was due to that it is not possible to use diserial the way I did with local baudrate timer in the SCC device. I got it nearly to work one way as can be seen above but when sending keypresses the other way there was problems. The SCC device wasn't producing exactly the right baud rate but nearly enough to being able to send characters from the board to the terminal, but in the opposite direction there was not start bit detection and there was no mid bit alignment in the SCC device. Even after adding that it turned out that I didn't get the final transmitt_complete because it also had no stop bit detection... So I relized I was reimplementing diserial in the SCC device and after I relized that it took me just 20 minutes to implement the baudrate timer using the diserial setrate() functions. So that part is now rock solid compared to how it was and the MVME-147 driver was submitted a few days ago with a working 147-Bug> terminal. It has a lot of features to play with:

Some of this doesn't work yet since there are no devices behind the commands but it is a start and the 147-Bug supports booting an OS from disk and load code it is just a matter of complete the emulation :-)
_________________________
https://frakaday.blogspot.se/

Top
#105614 - 05/17/16 11:25 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
The next board I am working on is the MVME-162 with a 68040 device and hve already got a prompt, or two actually! The first is called Raw-bug and is a ROM only monitor built in to the firmware. It requires no RAM and I was dropped into that after setting up the SCC but with no RAM in the system. Once I configured some RAM the 162-Bug started up:

The 162-Bug also has loads of commands to play with:

I hope to be able to submit the first version soon and then start to reduce the diagnostics errors.
_________________________
https://frakaday.blogspot.se/

Top
#105630 - 05/18/16 01:38 PM Re: VME boards [Re: Edstrom]
rfka01 Offline
Senior Member

Registered: 01/01/12
Posts: 597
Loc: Bavaria
Edstrom, amazing progress! I love seeing these old machines coming alive again! smile
_________________________
NCR DMV- DEC Rainbow- Siemens PCD- ITT 3030-Oly People- Acorn A5000- Olivetti M20

Top
#105634 - 05/18/16 03:23 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Yeah me too, its kind of low hangning fruits though to just hook up the serial port but it gives a lot of possibilities to boot software. The problem is to get relevant software for these machines. Sure a UNIX or OS9 would be fun to hook up but it would be even better to get some ROM:s from an industrial system that really did something, from a sawmill or so smile
_________________________
https://frakaday.blogspot.se/

Top
#105635 - 05/18/16 03:42 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
BTW, I am looking at the IndustryPack module, ( IP module), standard that was adopted by the MVME162 as a local bus.

http://www.powerbridge.de/download/specs/IndustryPack-Spezifikation,%20Draft%201.0.d.0.pdf

Quite nice little interface/bus with around 100 boards implemented according to Wikipedia:

https://en.wikipedia.org/wiki/GreenSpring_Computers



Edited by Edstrom (05/18/16 03:43 PM)
_________________________
https://frakaday.blogspot.se/

Top
#105638 - 05/18/16 07:06 PM Re: VME boards [Re: Edstrom]
rfka01 Offline
Senior Member

Registered: 01/01/12
Posts: 597
Loc: Bavaria
Looks like a perfect case to show off MAME's versatility.
Get your virtual sawmill going, though, that would be a hoot smile

Shame my friend Chris is no longer around ... he designed and built those stone saws

http://steinbearbeitungsmaschinen.de/index.php?rex_resize=600h__heigl_ksl_-_pratz.jpg

but iirc with Siemens SPS S5 controllers.
_________________________
NCR DMV- DEC Rainbow- Siemens PCD- ITT 3030-Oly People- Acorn A5000- Olivetti M20

Top
#105640 - 05/18/16 10:31 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Cool, these are real computers! :))
_________________________
https://frakaday.blogspot.se/

Top
#105965 - 06/08/16 02:51 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Slight progress with the Force CPU-30 driver.

The new DUSCC serial device I am working on let some characters out of it! The DUSCC is really much more complex than the SCC but much less successful. Hopefully there are other boards using this chip out there.

I have also improved the 68230 device and added a FGA-002 gate array skeleton device. I'll submit it as soon as I get input to work also.

_________________________
https://frakaday.blogspot.se/

Top
#105967 - 06/08/16 04:29 PM Re: VME boards [Re: Edstrom]
Al Kossow Offline
Senior Member

Registered: 01/06/11
Posts: 147
The docs for the MVME6000 bus controller used on the MVME147 is up on bitsavers now.

Top
#105970 - 06/09/16 11:52 AM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
I found out that there are DUSCC designs from Force Computers and some models from DEC, a microserver and a DECrouter-150/-250.

I got the ISIO-1 firmware which includes DUSCC diagnostics(!) so I will hook it up to test the DUSCC implementation.

I have nothing on the DEC stuff yet. VME interfaces are next.
_________________________
https://frakaday.blogspot.se/

Top
#105996 - 06/10/16 11:49 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298

Hmm, I just added the official ROM:s for the ISCSI-1 VME board and they look very similar to the ROM:s from the Besta 88 computer smile

_________________________
https://frakaday.blogspot.se/

Top
#106008 - 06/11/16 04:13 PM Re: VME boards [Re: Edstrom]
crazyc Offline
Senior Member

Registered: 01/22/12
Posts: 634
Compare the mc7105 to the vt240 and you'll see the same thing.

Top
#106009 - 06/11/16 05:26 PM Re: VME boards [Re: Edstrom]
R. Belmont Offline

Very Senior Member

Registered: 03/17/01
Posts: 15487
Loc: USA
Hah, that's pretty funny. I guess the CPU wasn't the only thing they cloned smile

Top
#106025 - 06/13/16 11:23 AM Re: VME boards [Re: Edstrom]
shattered Offline
Senior Member

Registered: 05/30/12
Posts: 378
Yeah, peripherals and software too were cloned. There's a interesting document (circa 1983) on experience gained from working with IBM System/360 clones (the ES EVM series) -- http://tapemark.narod.ru/cejtin.html -- Google does a nice job translating it.

Top
#106355 - 07/04/16 10:19 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Is the 68030 cycle accurate enough for register to register calculations and DIV arithmetics? The Force CPU-30 firmware code below uses the timer to meassure the time it takes to execute some code to determine what CPU is on the board. Should it work? If so I need to fix the timer I just implemented.

Code:
FFE033C6: movem.l D1-D6/A5, -(A7)
FFE033CA: movec CACR, D2; (2+)
FFE033CE: move.l  D2, -(A7)
FFE033D0: moveq   #$0, D1
FFE033D2: movec D1, CACR; (2+) // Disable cache
FFE033D6: move    SR, D3
FFE033D8: move.l  D3, -(A7)
FFE033DA: move    #$2700, SR   // Disable all interrupts
FFE033DE: lea     $ff800e00.l, A5 // 68230 PIT base
FFE033E4: move.b  #$0, ($10,A5)  // TCR - timer disabled 
FFE033EA: move.b  #$ff, ($13,A5) // Preload Hi
FFE033F0: move.b  #$ff, ($14,A5) // Preload Mid
FFE033F6: move.b  #$ff, ($15,A5) // Preload Lo
FFE033FC: move.l  #$4e20, D0
FFE03402: move.l  #$3, D1
FFE03408: move.l  #$2, D2
FFE0340E: move.l  #$2, D3
FFE03414: move.b  #$1, ($10,A5) // Timer enabled
FFE0341A: move.l  D2, D4
FFE0341C: move.l  D3, D5
FFE0341E: move.l  D1, D6
FFE03420: divs.l  D6, D2:D3; (2+)
FFE03424: subq.l  #1, D0
FFE03426: bne     $ffe0341a // loop for $4e20 times
FFE0341A: move.l  D2, D4
FFE0341C: move.l  D3, D5
FFE0341E: move.l  D1, D6
FFE03420: divs.l  D6, D2:D3; (2+)
FFE03424: subq.l  #1, D0
FFE03426: bne     $ffe0341a // loop for $ffffffff times

   (loops for 119988 instructions)

FFE03428: move.b  #$0, ($10,A5) // disable timer
FFE0342E: moveq   #$0, D0
FFE03430: move.b  ($17,A5), D0 // counter register Hi
FFE03434: lsl.l   #8, D0
FFE03436: move.b  ($18,A5), D0 // counter register Mid
FFE0343A: lsl.l   #8, D0
FFE0343C: move.b  ($19,A5), D0 // counter register Low
FFE03440: not.l   D0
FFE03442: lsr.l   #4, D0
FFE03444: lea     ($22,PC), A5; ($ffe03468)
FFE03448: move.w  (A5)+, D1
FFE0344A: cmp.w   D1, D0     // Apparantly looking up timer result in table
FFE0344C: bhi     $ffe03454
FFE03450: addq.l  #2, A5
FFE03452: bra     $ffe03448
FFE03448: move.w  (A5)+, D1
FFE0344A: cmp.w   D1, D0
FFE0344C: bhi     $ffe03454
FFE03450: addq.l  #2, A5
FFE03452: bra     $ffe03448

EDIT: Apparantly this is only for the clock detection of the board and I am currently off by a factor two approximately but still outside the table and got the default which is 36MHz instead of 16MHz.. So I have probably missed a divider in the data sheet, but still not close enough..


Edited by Edstrom (07/04/16 11:23 PM)
_________________________
https://frakaday.blogspot.se/

Top
#106367 - 07/05/16 11:50 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
The board is actually 25MHz, and after correcting that and trying to find the factor of error to get the right table entry, I find that a factor of 5 identifies a 20MHz board and a factor of 4 a 36MHz board, so it isn't just a simple divider or two that needs to be corrected.

I believe that the factor is 4, 2 from the counter and 2 from the prescaler, where I count both raising and falling edges currently, does that makes sense? However, if that is correct I am still off by some meassure. Here is the table:

As you can see the difference between the 25MHz I want to get and the 20MHz I get is only 0x200 shifted 4 so times 16 = 0x2000 which is far from the 20% I would expect. How does that work? Any hint in the right direction appreciated, even smaller insults.
_________________________
https://frakaday.blogspot.se/

Top
#106379 - 07/06/16 08:18 AM Re: VME boards [Re: Edstrom]
Olivier Galibert Offline
Senior Member

Registered: 06/02/01
Posts: 360
Loc: somewhere else entirely
The 030 cycle counts are far from perfect. I don't think "div" has ever been closely studied there (it has for the original 68000, but that it), and even for the simple instructions I had to hack a cycle count to make the next timing test pass. We have problems there, the cache, and maybe even the 010 loop mode, being probably a part of them.

OG.

Top
#106381 - 07/06/16 09:01 AM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Ok, thanks, as I suspected that and it also means that we will not pass these tests and choose the right board profile for the asic right now, unless I do some board driver trickery with the PIT clock etc, so we can start the firmware correctly.

The firmware also seem to support different memory maps based on different table lookups, with some jumper settings I get to poll loops that doesn't match the assumed CPU-30 memory map. Some others I get a terminal but so far I have not got the right banner and board speed.

I start filling in the blanks in the FGA-002 for the CPU-30 now since I think there is a CPU-40 firmware coming in soon.


Edited by Edstrom (07/06/16 09:02 AM)
_________________________
https://frakaday.blogspot.se/

Top
#106384 - 07/06/16 02:30 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Some progress at last, but more out of luck, setting the jumpers "randomly" (not really) finally booted up the CPU-33 firmware, guess I have to tweak the driver to reflect that board now, and I can trace how a good table lookup looks like. Eyring Research indicates that a PDOS RTOS kernel is available as expected. :-)
_________________________
https://frakaday.blogspot.se/

Top
#106386 - 07/06/16 03:22 PM Re: VME boards [Re: Edstrom]
R. Belmont Offline

Very Senior Member

Registered: 03/17/01
Posts: 15487
Loc: USA
Nice!

Top
#106387 - 07/06/16 04:39 PM Re: VME boards [Re: R. Belmont]
Just Desserts Offline
Very Senior Member

Registered: 05/23/09
Posts: 1572
I'm genuinely curious, what sorts of things were these boards typically used for? Industrial automation and control for things that needed more horsepower than a simple PLC, or what? It's very cool to see these weird, obscure things getting emulated!

Top
#106388 - 07/06/16 04:56 PM Re: VME boards [Re: Just Desserts]
Al Kossow Offline
Senior Member

Registered: 01/06/11
Posts: 147
Originally Posted By Just Desserts
I'm genuinely curious, what sorts of things were these boards typically used for? Industrial automation and control for things that needed more horsepower than a simple PLC, or what? It's very cool to see these weird, obscure things getting emulated!


Tons of things used them, instruments, lab experiments, radio telescopes, :-)

The main source for information on these boards nowadays are laboratories that have stuff running (still) that they're trying to support.

There are bunches of boards on eBay, mostly with insane prices because of the market for spares to keep this equipment alive.


Edited by Al Kossow (07/06/16 04:58 PM)

Top
#106401 - 07/06/16 08:56 PM Re: VME boards [Re: Edstrom]
R. Belmont Offline

Very Senior Member

Registered: 03/17/01
Posts: 15487
Loc: USA
It was a supported upgrade for VME Sun2s to swap the CPU board for a Sun3 and later a Sun4. This is why a lot of older VME cards from Sun were supported in the boot PROMs all the way through the SPARC machines. It's also why the ID PROM stayed pin-compatible all that time; you were meant to carry your old ID PROM forward when you upgraded so your MAC address and machine ID stayed the same and copy-protected software was happy. That finally ended with sun4c and SBus.

Wiki says the Atari TT's system bus was VME but it apparently wasn't brought out to any VME-compatible connectors.


Edited by R. Belmont (07/06/16 08:57 PM)

Top
#106402 - 07/06/16 09:00 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
In the embedded world these systems were on the border land between UNIX and RTOS long before Linux came along and blurred the view. In a VME chassi you typically had a few to loads of deterministic data gathering boards which were aggregating data to a main CPU which also could act on the data and control the machinery through other VME interface boards. The main CPU typically ran a user interface under OS9/UNIX or somethings else, later both Sun and Microsoft (and even Apple right?) tried to own that main CPU board. Sometimes the data was just passed on to a "normal" computer or a PC over ethernet, or to another VME chassi for further processing. These could be huge systems or just a single VME board.

A typical system suitable for VME boards were usually very complex or in too small series to develop a custom board/system. While VME was expensive it still did cut out quite some development costs. VME projects I have been working with as a supplier as far as I remember includes:

- Drill robot for mines with 3D vector projections
- Robot control prototypes
- High sea (waves) compensation system for Hydrofoil boats
- Accellerator rings
- Test equipment for the Arianne rockets
- Sawmills
- Automated manufacturing
- Telephone exchange systems

Sometimes the systems were used for development prototyping only but sometimes they just kept buying crates which was great of course. My part was to among others to write drivers bundled in so called BSP:s for the boards supporting the particular RTOS/OS the customer were using, in our case mostly VRTX and VxWorks. Lots of fun smile



Edited by Edstrom (07/06/16 09:02 PM)
_________________________
https://frakaday.blogspot.se/

Top
#106574 - 07/22/16 11:20 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Here are some pictures of the fantastic Heurikon posters that I used to decorate our office back then: http://www.briandonahoe.com/PhotoAlbum/Heurikon/index.html
_________________________
https://frakaday.blogspot.se/

Top
#106575 - 07/23/16 02:01 AM Re: VME boards [Re: Edstrom]
R. Belmont Offline

Very Senior Member

Registered: 03/17/01
Posts: 15487
Loc: USA
Those are awesome smile

Top
#106595 - 07/24/16 11:04 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
I think I need some advice here. I have interrupts going from the serial controller to the gate array which directly interfaces the IPL0-IPL2 on the 68030. The gate array allows the interrupt level to be programmed individually for each connected device (8 local, 8 vme and some special interrupt sources) as well as edge/flank, assert level etc.

I have setup the serial device *int_cb to call the fga device which in turn figures out the level and calls its *int_cb which is connected to the fccpu30 board driver handler which looks like this:
Code:
WRITE_LINE_MEMBER(fccpu30_state::fga_irq_callback)
{
	LOGINT(("%s(%02x)\n", FUNCNAME, state));

	m_maincpu->set_input_line(INPUT_LINE_IRQ0, state & (1 << 0));
	m_maincpu->set_input_line(INPUT_LINE_IRQ1, state & (1 << 1));
	m_maincpu->set_input_line(INPUT_LINE_IRQ2, state & (1 << 2));
}

I get this far but: Firstly the state doesn't pass on the level, it is just asserted or not. So what is the best way pass the level?

Secondly, both the gate array and the serial device can provide the vector, how is the correct daisy_irq_ack() called?
_________________________
https://frakaday.blogspot.se/

Top
#106722 - 08/01/16 10:32 AM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
I now got something that works, I have added an iack() callback function in the devices that will return the vector. These are configured from the board driver like this:
Code:
	/* FGA-002, Force Gate Array */
	MCFG_FGA002_ADD("fga002", 0)
	MCFG_FGA002_OUT_INT_CB(WRITELINE(fccpu30_state, fga_irq_callback))
	MCFG_FGA002_OUT_LIACK4_CB(DEVREAD8("duscc",  duscc_device, iack))
	MCFG_FGA002_OUT_LIACK5_CB(DEVREAD8("duscc2",  duscc_device, iack))

And there is also an INT callback from the device to the FGA chip like this:
Code:
	// DUSCC1&2 interrupt signal REQN is connected to LOCAL IRQ4&5 of the FGA-002 and level is programmable
	MCFG_DUSCC_OUT_INT_CB(DEVWRITELINE("fga002", fga002_device, lirq4_w)) 
	MCFG_DUSCC_OUT_INT_CB(DEVWRITELINE("fga002", fga002_device, lirq5_w))


I would also like to propose an iack() standard api where the vector is returned OR return codes for NO_VECTOR and IACK_TIMEOUT. I have implemented this for the hookup above and will add it to the rest of the devices unless someone tells me that it should be done differently, just let me know.


Edited by Edstrom (08/01/16 10:32 AM)
_________________________
https://frakaday.blogspot.se/

Top
#106739 - 08/02/16 11:46 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
With two terminals and some early interrupt support from the DUSCC serial controller through the FGA002 asic to the Force CPU-30 I finally managed to get some response from the CPU-30 firmware (right terminal) beyond the bootstrap which was polled only (left terminal). I guess there are some board jumpers that directed the VxWorks roms to try to boot from disk and there should be a way to get a shell prompt directly from VxWorks I think, unless compiled without the shell...
_________________________
https://frakaday.blogspot.se/

Top
#107166 - 09/07/16 10:48 AM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298

Finally got the interrupts working on the Force CPU-30 through two rather new devices, the DUSCC and FGA ASIC, the biggest problem was due to I didn't understand the representation of interrupts in the 68k core and how the iack cycle worked in MAME. I am closer to understanding that now... I think. smile

So next step I will clean up the code, add all the interrupt sources and see where we are. I switched back from VxWorks to VMEPROM since it is the in house RTOS but that will be selectable by a port setting jumper. Also VxWorks imediatelly want to mount/boot a disk so I need to add the controller to get past that. It is possible that VxWorks requires some software on the hard disk also.


Edited by Edstrom (09/07/16 04:02 PM)
_________________________
https://frakaday.blogspot.se/

Top
#107802 - 11/01/16 10:09 PM Re: VME boards [Re: Edstrom]
shattered Offline
Senior Member

Registered: 05/30/12
Posts: 378
a bit of hacking and poking into its shared command ram with debugger, and fcscsi at least tries to read the floppy (but fails):

Code:
[:] void fcscsi1_state::led_w(address_space&, offs_t, uint8_t, uint8_t) [1f]
[:] uint8_t fcscsi1_state::tcr_r(address_space&, offs_t, uint8_t)
[:] void fcscsi1_state::tcr_w(address_space&, offs_t, uint8_t, uint8_t) [1d]
[:fdc] Event fired for timer TM_CMD
[:fdc] SPINUP_WAIT
[:fdc] SPINUP_WAIT
[:fdc] SPINUP_WAIT
[:fdc] SPINUP_WAIT
[:fdc] SPINUP_WAIT
[:fdc] SPINUP_WAIT
[:fdc] SPINUP_WAIT
[:fdc] SPINUP_WAIT
[:fdc] SPINUP_WAIT
[:fdc] SPINUP_WAIT
[:fdc] SPINUP_WAIT
[:fdc] SPINUP_WAIT
[:fdc] SPINUP_DONE
[:fdc] SEEK_WAIT_STEP_TIME
[:fdc] SEEK_WAIT_STEP_TIME
[:fdc] Event fired for timer TM_GEN
[:fdc] SEEK_WAIT_STEP_TIME_DONE
[:fdc] SEEK_DONE
[:fdc] Event fired for timer TM_TRACK
[:mc68450] DMA#1: Operation Control write : 82
[:mc68450] DMA: Transfer begins: size=0x00000200
[:mc68450] DMA#1: Channel Control write : 80
[:fdc] Event fired for timer TM_SECTOR
[:fdc] Event fired for timer TM_CMD
[:fdc] read sector (c=88) t=0, s=1
[:fdc] SPINUP
[:fdc] SPINUP_DONE
[:fdc] SETTLE_DONE
[:fdc] SCAN_ID_FAILED

Top
#107804 - 11/02/16 05:52 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Nice! smile
_________________________
https://frakaday.blogspot.se/

Top
#107811 - 11/04/16 12:41 AM Re: VME boards [Re: Edstrom]
shattered Offline
Senior Member

Registered: 05/30/12
Posts: 378
First successful read smile

Code:
[:mc68450] DMA#1: Operation Control write : 82
[:mc68450] DMA: Transfer begins: size=0x00000200
[:mc68450] DMA#1: Channel Control write : 80
[:mc68450] DMA#1: End of transfer


Next up -- try to copy floppy to another floppy using this controller's BACKUP feature.

Top
#107812 - 11/04/16 11:08 AM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Still just playing around with the shared memory interface or are you adding code to the driver?! I guess I need to take on the VME bus again sooner or later so we can control that board from a CPU board smile
_________________________
https://frakaday.blogspot.se/

Top
#107813 - 11/04/16 01:12 PM Re: VME boards [Re: Edstrom]
shattered Offline
Senior Member

Registered: 05/30/12
Posts: 378
Adding code, yes ("1 file changed, 75 insertions(+), 6 deletions(-)") -- will submit that soon.

re: VME -- yes please smile Besta docs mention a few HD64384-based graphics boards, probably for CAD use, and I think the person who gave me iscsi docs may have manuals for those too.

Top
#107818 - 11/05/16 12:09 AM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Gah, I just started to look at the Force CPU-40 and it has the same FGA init but then the fun part starts with a table driven gibberish
setup of the DUSCC, dont't worry about the wrong baud rates, they make assumptions from CPU30 atm. There you go, a high level
language programmer has a table of constants and just changes the bits needed to get it to work. Compare that to the nice clean setup of the FGA in the beginning:

Code:
 * DUSCC #1 channel A setup 1 sequence FGA-002 firmware (polled i/o)
 *  A Reg 0f <- 00 - reset Tx Command
 *  A Reg 0f <- 40 - reset Rx Command
 *  A Reg 00 <- 07 - Async mode
 *  A Reg 01 <- 38 - Normal polled or interrupt mode, no DMA
 *  A Reg 04 <- 7f - Tx 8 bits, CTS and RTS, 1 STOP bit
 *  A Reg 06 <- 1b - Rx RTS, 8 bits, no DCD, no parity
 *  A Reg 05 <- 3d - Tx BRG 9600 (assuming a 14.7456 crystal)
 *  A Reg 07 <- 2d - Rx BRG 9600 (assuming a 14.7456 crystal)
 *  A Reg 0e <- 27 - TRxC = RxCLK 1x, RTxC is input, RTS, GPO2, crystal oscillator connected to X2
 *  A Reg 0b <- f1 - RTS low, OUT1 = OUT2 = high, RxRdy asserted on FIFO not empty
 *                   TxRdy asserted on FIFO not empty, Same Tx Residual Character Length as for REG_TPR
 *  A Reg 0f <- 00 - reset Tx Command
 *  A Reg 0f <- 40 - reset Rx Command
 *  A Reg 0f <- 02 - enable Tx Command
 *  A Reg 0f <- 42 - enable Rx Command
 *--- end of FGA setup sequence ---
 *  :dusccA Reg 00 <- ff CMR1 Async mode, no parity
 *  :dusccA Reg 01 <- 80 Local loopback mode
 *  :dusccA Reg 02 <- 20 Character Compare
 *  :dusccA Reg 03 <- 01 Not used in Async mode
 *  :dusccA Reg 08 <- 00 Counter/Timer Preset High 
 *  :dusccA Reg 09 <- 5f Counter/Timer Preset Low
 *  :dusccA Reg 0a <- 00 Counter Timer Control
 *  :dusccA Reg 0b <- 00 OMR 
Tx Residual Character Length is 1 bits
- TxRDY activated by FIFO not full
- RxRDY activated by FIFO not empty
- GP02, if configured as output, is: 1
- GP01, if configured as output, is: 1
- RTS, either pin if configured as output, is: 1
 *  :dusccA Reg 04 <- 00 TPR Transmit Parameter Register
- RTS 0
- CTS 0
- Stop Bits 1
- Data Tx bits 5
- RX:32x
- TX:32x
 *  :dusccA Reg 05 <- f0 
- External source: TRxC
- Transmit Clock: 32x own channel C/T - not implemented
- BRG Tx rate 50 assuming a 14.7456MHz CLK crystal
 *  :dusccA Reg 06 <- 00 
- RTS output 0      
- Strip Parity 0    
- DCD/SYNIN input 0 
- Data Rx bits 5    
- RX:32x  
- TX:1x   
 *  :dusccA Reg 07 <- 0a 
- External source: RTxC
- Receiver Clock: 1x External - not implemented
- BRG Rx rate 2000 assuming a 14.7456MHz CLK crystal
- RX:1x
- TX:1x
 *  :dusccA Reg 04 <- 00 
- RTS 0
- CTS 0
- Stop Bits 1
- Data Tx bits 5
- RX:32x
- TX:32x
 *  :dusccA Reg 05 <- f0 
- External source: TRxC
- Transmit Clock: 32x own channel C/T - not implemented
- BRG Tx rate 50 assuming a 14.7456MHz CLK crystal
 *  :dusccA Reg 06 <- 00 
- RTS output 0      
- Strip Parity 0    
- DCD/SYNIN input 0 
- Data Rx bits 5    
- RX:32x  
- TX:1x   
 *  :dusccA Reg 07 <- 8a 
- External source: TRxC
- Receiver Clock: 1x External - not implemented
- BRG Rx rate 2000 assuming a 14.7456MHz CLK crystal
- RX:1x
- TX:1x
_________________________
https://frakaday.blogspot.se/

Top
#107827 - 11/06/16 01:34 PM Re: VME boards [Re: Edstrom]
shattered Offline
Senior Member

Registered: 05/30/12
Posts: 378
iscsi/floppy PR sent -- https://github.com/mamedev/mame/pull/1641

How to demo: attach a 720K floppy image to drive 0, wait for selftests to pass and enter debugger:

Code:
; configure unit 0 as QD floppy (80 tracks, 2 sides, 9 spt)
do b@2300=2
do b@2301=50
do b@2302=9
do b@2303=0
do b@2304=2
do b@2305=1
do b@2306=ee
do b@2307=0
do b@2308=1
; equivalent:
do q@2300=25009000201ee00

do b@2308=1

do d@2104=2300
do w@210c=0
; target 7, command 0x0a
do w@2100=e0a

; read lbn 0 -- data will be at 0x4000 in memory

do w@2102=1
do d@2104=0
do d@2108=4000
do w@210c=0
do w@2100=e20

Top
#107829 - 11/06/16 03:31 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
I saw you enabled the SCSI stuff too, would be cool to do the same thing with a HDD! or is there a boot able floppy for Force CPU30 out there?
_________________________
https://frakaday.blogspot.se/

Top
#107832 - 11/06/16 05:35 PM Re: VME boards [Re: Edstrom]
shattered Offline
Senior Member

Registered: 05/30/12
Posts: 378
SCSI stuff won't work until NCR5385E/NCR5386 device is written -- I've only added a stub to make self-test pass smile

Yes, there is a floppy (from Linux/Besta port) -- two, in fact: flop800.* on http://ftp.stu.neva.ru/besta/linux-bin/

But neither is designed for CPU30R4 -- one is for 'CP31' board (could be an earlier revision of CPU30) and another for 'HCPU30'.

Top
#107838 - 11/06/16 09:17 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Ok, it is on my list to add all the variants of the boards too, should be pretty stright forward I think. The CPU30 has a floppy controller too on P2 connecor, not sure about the CPU-31 one though. I wonder if the besta floppy will boot. smile
_________________________
https://frakaday.blogspot.se/

Top
#107839 - 11/06/16 09:44 PM Re: VME boards [Re: Edstrom]
shattered Offline
Senior Member

Registered: 05/30/12
Posts: 378
far as I can see from the docs, the non-Force boards are
Code:
cp31	= cp30 + rtc
	68030, 68882 @ 33 MHz
	68153 BIM	$FF800800
	68230 PIT	$FF800C00
	68561 MPCC	$FF800000
	62421 RTC	$FF800A00
	Centronics	$ff800200 ???
	:
	32KB 0ws SRAM	$FF04xxxx..$FF07xxxx
	256KB EPROM	$FF00xxxx..$FF03xxxx
	:
	MPCC #2, #3	$ff800200, $0xff800600	optional, on SRAM daugtherboards

cp33	=
	68030, 68882 @ 25 or 33 MHz
	EPROM -- 512KB, 1MB or 2MB
	DRAM -- up to 64MB
	:
	console MPCC	$FF800000		only in prototypes, later models move console to 2681
	68153 BIM	$FF800800
	68230 PIT	$FF800C00
	62421 RTC	$FF800A00
	WD33C93A SCSI	$FF801000 & $FF810000 (dma)
	i82077 FDC	$FF801200
	CENC (parallel)	$FF800200
	SCN2681		$FF801400
	IRQRG		$FF801600
	Am7990 LANCE	$FF820000

hcpu30	=
	68030, 68882 @ 33 MHz
	68020 -- I/O cpu
	:
	DRAM -- 4 or 16 MB
	PROM -- up to 64 KB
	SRAM -- 8 KB non-volatile or 32 KB volatile
	:
	2xRS232/RS422	$FFFF8120, $FFFF8140
	SCSI		$FFFF8160
	Floppy		$FFFF8260
	Centronics	$FFFF8280
	RTC		$FFFF8100
	Ethernet	$FFFF82A0


Linux port supports CP20, CP30, CP31 and HCPU. Don't know what SysV supports -- there are boot floppies for that, too.


Edited by shattered (11/06/16 09:56 PM)

Top
#107845 - 11/07/16 04:28 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Great, I will try booting one of the Linux floppy images on a CPU-30 when I get there. smile

Right now I am swearing because I just found out that the poor CPU-40 init code I pointed out is even worse, it seem that the PIT and the DUSCC gets the *same* init sequence. This indicates that some table driven init assumes something I don't reflect at the moment, such as a proper board ID or relocated devices, need to dig deeper before the CPU-40 board will start producing any output. The FGA-002 is updated too since the new init is 4.x vs 3.x for the CPU-30 and there are a lot of new registers. I need to park that for a moment, thought it would be easy! smile
_________________________
https://frakaday.blogspot.se/

Top
#107847 - 11/07/16 06:04 PM Re: VME boards [Re: Edstrom]
shattered Offline
Senior Member

Registered: 05/30/12
Posts: 378
ah, but CPU-30 <> CP30. docs say that CP30 is CPU-25M and CP20 is CPU-25 smile

here's a photo of CP30: https://img-fotki.yandex.ru/get/3803/bushjr.1/0_168f0_d275a7e0_orig

Top
#107850 - 11/07/16 09:38 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
The CPU-25 has a Rockwell 68561 MPCC chip. Considering the huge register layout difference to the Signetics 68562 DUSCC used on later Force products I am quite sure an ignorant purchaser made a great deal with Signetics thinking that the difference should be small, which it is on a feature lavel. Software guys must have cried for weeks..
_________________________
https://frakaday.blogspot.se/

Top
#107851 - 11/07/16 10:26 PM Re: VME boards [Re: Edstrom]
shattered Offline
Senior Member

Registered: 05/30/12
Posts: 378
Who knows... It's been a while since I've seen a working Besta, so can't check what's actually installed; chips on this board may have been replaced after it was pulled (notice there's no CPU smile )

Top
#107894 - 11/14/16 12:44 AM Re: VME boards [Re: Edstrom]
AJR Offline
Member

Registered: 12/17/15
Posts: 38
The CPU-30's RTC72423 could probably just use the existing MSM6242 device. Epson's RTC72421 (DIP) and RTC72423 (SOP) seem to be mostly pin-compatible with the RTC62421 and RTC62423 mentioned in the device file, with the only difference being the lack of an external XTAL hookup.

Top
#107895 - 11/14/16 02:10 AM Re: VME boards [Re: Edstrom]
R. Belmont Offline

Very Senior Member

Registered: 03/17/01
Posts: 15487
Loc: USA
They're pin-compatible, but are they register-compatible?

Top
#107896 - 11/14/16 02:30 AM Re: VME boards [Re: Edstrom]
AJR Offline
Member

Registered: 12/17/15
Posts: 38
Yes, the control registers (CD, CE, CF) have the same location and format.

Top
#107897 - 11/14/16 09:06 AM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Great, I'll have a look! smile
_________________________
https://frakaday.blogspot.se/

Top
#107899 - 11/14/16 11:11 AM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Seems to work just fine: smile

EDIT: at least it displays the time when started, it doesn't count yet. Figure the interrupt needs some tuning or something...


Edited by Edstrom (11/14/16 11:18 AM)
_________________________
https://frakaday.blogspot.se/

Top
#107900 - 11/14/16 03:53 PM Re: VME boards [Re: Edstrom]
Al Kossow Offline
Senior Member

Registered: 01/06/11
Posts: 147
yay!

Top
#107901 - 11/14/16 06:15 PM Re: VME boards [Re: Edstrom]
shattered Offline
Senior Member

Registered: 05/30/12
Posts: 378
27 years and counting smile

Top
#108345 - 01/04/17 09:19 PM Re: VME boards [Re: Edstrom]
os9er Offline
Member

Registered: 11/20/15
Posts: 2
As a big fan of 68k, and old-time user of MVE hardware, I'm enjoying seeing the progress on this emulation.

It would be great to seeing it boot Motorola UNIX or OS-9/68k!

There are images of the Motorola 68k port of AT&T System V for VME in the bitsaver's archive. Something like this would also be great for working on the Linux m68k port.

As an aside, as an encore, if you ever want to do the m88k VME hardware I have a copy of Motorola UNIX for that somewhere, I think.

Top
#108346 - 01/04/17 10:13 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Nice to get some feedback as this is a long term project for me and there are so much I'd like to do with the VME. smile

We are still at early emulations and recently I pushed the first actual VME bus enabled drivers and I will soon enable all the existing VME SBC board drivers and add more as I got hold of firmwares and/or board documentations.

This will enable exploration of the device support in the existing board firmwares we have and add supported slave boards such as FDD, HDD and SCSI boards. When that is done we will have a lot more software to play with.

Right now I'd like to get more VME board firmwares and documentations as well as specialized firmwares for industrial control applications even though the latter probably will be unducumented it will teach us a lot how these systems were built. Apart from 68K VME I'd like to see 960, Sparc, 386 and obviously 88K up and running one day, but first the bus must be more complete and 68K booting something substantial.
_________________________
https://frakaday.blogspot.se/

Top
#108356 - 01/06/17 06:32 AM Re: VME boards [Re: Edstrom]
os9er Offline
Member

Registered: 11/20/15
Posts: 2
I've long since sold my VME stuff, unfortunately, so I don't have any way to come up with firmware images from the devices, except to ask a buddy of mine who is heavy into retro collecting. He is the guy that got all my VME stuff, actually. I'm not sure if he still has it; he is trading away stuff all the time, but I'll ask.

However, I do have some assembler source for driver code, if you're interested. Not sure what sort of docs for VME I might still have around. I'll look.

PM me.

Top
#108476 - 01/18/17 12:32 AM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Here is a nice VME system with Connected Apple Lisas and VAX computers (see the figure on page 261) used by CERN
It would be nice to emulate just a fraction of it smile The problem is of course to get all the software involved,
very custom and probably at the dump by now. It is quite detailed in the paper linked above though.
_________________________
https://frakaday.blogspot.se/

Top
#108478 - 01/18/17 03:44 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
I finally got the first printouts on the Force CPU-20 PDOS bootstrap working with the new MPCC 68561 device:

_________________________
https://frakaday.blogspot.se/

Top
#108508 - 01/20/17 10:00 AM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
And now the keyboard works as well as some jumpers emulated so we fall into FORCEbug rather than trying to auto boot some so far non existing floppy disk.
This is rather cool as it is FOREbug and not VMEprom, PDOS is not integrated but separated. later on the VMEprom replaces FORCEbug and all it s functionality and also integrating a PDOS kernel.




Next thing will be to load the fccpu20 in the miniforce chassi previously skeltonized and now I want to explore how the VME bus calls can be dispatched between the boards.
Yet then we need to write the WFC1 mass storage controller board to get to the floppy controller.


Edited by Edstrom (01/20/17 10:01 AM)
_________________________
https://frakaday.blogspot.se/

Top
#108512 - 01/20/17 08:32 PM Re: VME boards [Re: Edstrom]
shattered Offline
Senior Member

Registered: 05/30/12
Posts: 378
besta.cpp (CP31 board, essentially Force CPU-25M + RTC chip):



diff: https://gist.github.com/shattered/4ec094bc1fcee96c6980a9fc5762069b

Top
#108513 - 01/20/17 08:54 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
if you enable LOGSETUP by

#define VERBOSE (LOG_PRINTF | LOG_SETUP)

you'll get output about what it tries to do and what is not implemented
_________________________
https://frakaday.blogspot.se/

Top
#108519 - 01/21/17 02:37 PM Re: VME boards [Re: Edstrom]
shattered Offline
Senior Member

Registered: 05/30/12
Posts: 378
'cp31dssp' BIOS apparently doesn't like something here:

Code:
[:mpcc]  * : Reg 19 -> 1e  
[:mpcc]  * : Reg 1c -> 8c  
[:mpcc]  * : Reg 1d -> 00  
[:mpcc]  * : Reg 1e -> 1c  
[:mpcc]  * : Reg 1f -> 00  
[:mpcc]  * : Reg 0d -> 00  
[:mpcc]  * : Reg 15 -> 00  
[:mpcc]  * : Reg 05 -> 80  
[:mpcc]  * : Reg 11 -> 40  
[:mpcc]  * : Reg 08 -> 80  


It prints 'MPCC ERROR' right after.

Top
#108523 - 01/21/17 08:34 PM Re: VME boards [Re: Edstrom]
Edstrom Offline
Senior Member

Registered: 08/11/15
Posts: 298
Can't determine without knowing how the initialization was done, I will come back to the MPCC when I have PDoS booting to add interrupts and a few other things but it may take a while, feel free to contribute to the MPCC meanwhile. Here is the data sheet, it is quite good actually:

https://drive.google.com/open?id=0B685nj_1DkduUndEUkx0UWJTY00
_________________________
https://frakaday.blogspot.se/

Top
Page 1 of 13 1 2 3 12 13 >

Who's Online
0 registered (), 14 Guests and 4 Spiders online.
Key: Admin, Global Mod, Mod
Shout Box

Forum Stats
4,728 Registered Members
9 Forums
8,281 Topics
107,022 Posts

Most users ever online: 225 @ 05/26/14 05:34 PM