|
|
Joined: May 2012
Posts: 555 Likes: 1
Senior Member
|
Senior Member
Joined: May 2012
Posts: 555 Likes: 1 |
I'm converting Besta to a slot device btw, the roms in there probably came from a "CP31" board (which could be a customized CPU30).
Last edited by shattered; 12/14/21 07:22 PM.
|
|
|
|
|
Joined: Aug 2015
Posts: 405
Senior Member
|
|
OP
Senior Member
Joined: Aug 2015
Posts: 405 |
I'm converting Besta to a slot device btw, the roms in there probably came from a "CP31" board (which could be a customized CPU30). Great, I am shaping up the vme_fcscsi.cpp right now and the fccpu20.cpp to get a bit further with Force focus32. Lets stay in sync if we need to change stuff in vme.cpp and other common files, I think I do.
Because I can
|
|
|
|
|
Joined: Aug 2015
Posts: 405
Senior Member
|
|
OP
Senior Member
Joined: Aug 2015
Posts: 405 |
Status of the VME bus device. So far the VME bus interface has mostly been a placeholder as it just installs a device on a VME card in the "maincpu"s address space on the VME CPU board, shortcutting the bus function itself. This is fine just to run a single cpu bord with a couple of different VME boards. As soon as you want to have multiple masters (CPU boards or DMA controllers etc) this will not work very well. There are two modes: - Direct install of devices into a single CPU boards address space. This mode is selected by calling vme_device::use_owner_spaces() from the card device configuration VME(config, "vme", 0).use_owner_spaces(); - Indirect install of board devices into a bus address space. Reads and writes from masters will be trampolined into the right device in the right VME address space. This allows multiple masters to work a single I/O board without the I/O board needs to know them on before hand. It will be slow but that is OK and also the nature of a VME bus, most intensive processing was using a local CPU anyway. The direct mode works already I believe while I am working on the Indirect mode for the A24 address space right now. I am struggling a bit how to translate byte and word accesses into the correct VME bus cycles translated to MAME cycles, and I am sure I will come out short, but never the less have some improvements. By all means, if someone is doing something similar for VME, just let me know.
Because I can
|
|
|
|
|
Joined: May 2012
Posts: 555 Likes: 1
Senior Member
|
|
Senior Member
Joined: May 2012
Posts: 555 Likes: 1 |
besta.cpp is now bus/vme/vme_cp31.cpp. It was probably a customized version of Force CPU30 series board. There are some technical manuals in Russian, but no schematics. HCPU30 board is more interesting, as it has onboard SCSI and Ethernet supported by MAME, a Linux 2.0 port with source, and schematics (but no PAL dumps). It needs significant updates to DUSCC emulation, some changes to DP8473, to NSCSI HD device (1024-byte sector buffer instead of 512) and probably more, as Unix and Linux weren't stable when I managed to boot them. I am trying to untangle my wip DUSCC code now 
|
|
1 member likes this:
Edstrom |
|
|
|
|
Joined: Aug 2015
Posts: 405
Senior Member
|
|
OP
Senior Member
Joined: Aug 2015
Posts: 405 |
I think I got the hang of it now, thx for all the work on the memory system OG (I guess) it is really not surprising me anymore and I got trampolines working from A32:D32 over A24:D32 to A32:D8/D16 now and the masks seems to do the work splitting calls into smaller ones etc. : :vmef32 virtual void vme_device::device_start()
- using VME memory spaces attached to :vmef32
- Done at 32 width
:vmef32 vme_device::install_device AM57 D32 00b02000-00b02150
:vmef32 vme_device::install_device AM57 D32 fcb00000-fcb001ff
virtual void vme_fcscsi1_card_device::device_start()
:vmef32 vme_device::install_device AM57 D32 00a00000-00a1ffff
:vmef32 vme_device::install_device AM57 D32 00c00000-00c3ffff
void vme_fccpu20_device::a24_w(offs_t, uint32_t, uint32_t): 00a00008 <- 77777777:00ff0000
void vme_fcscsi1_card_device::write8(offs_t, uint8_t) offset:09 data:77
void vme_fccpu20_device::a24_w(offs_t, uint32_t, uint32_t): 00a00008 <- 77777777:000000ff
void vme_fcscsi1_card_device::write8(offs_t, uint8_t) offset:0b data:77
void vme_fccpu20_device::a24_w(offs_t, uint32_t, uint32_t): 00a00000 <- 54545454:00ff0000
void vme_fcscsi1_card_device::write8(offs_t, uint8_t) offset:01 data:54
void vme_fccpu20_device::a24_w(offs_t, uint32_t, uint32_t): 00a00000 <- 54545454:000000ff
void vme_fcscsi1_card_device::write8(offs_t, uint8_t) offset:03 data:54
void vme_fccpu20_device::a24_w(offs_t, uint32_t, uint32_t): 00a02104 <- fca00000:ffffffff
void vme_fcscsi1_card_device::write8(offs_t, uint8_t) offset:2104 data:fc
void vme_fcscsi1_card_device::write8(offs_t, uint8_t) offset:2105 data:a0
void vme_fcscsi1_card_device::write8(offs_t, uint8_t) offset:2106 data:00
void vme_fcscsi1_card_device::write8(offs_t, uint8_t) offset:2107 data:00
void vme_fccpu20_device::a24_w(offs_t, uint32_t, uint32_t): 00a02100 <- 00030003:ffff0000
void vme_fcscsi1_card_device::write8(offs_t, uint8_t) offset:2100 data:00
void vme_fcscsi1_card_device::write8(offs_t, uint8_t) offset:2101 data:03
void vme_fccpu20_device::a24_w(offs_t, uint32_t, uint32_t): 00a02300 <- 00000000:ffffffff
void vme_fcscsi1_card_device::write8(offs_t, uint8_t) offset:2300 data:00
void vme_fcscsi1_card_device::write8(offs_t, uint8_t) offset:2301 data:00
void vme_fcscsi1_card_device::write8(offs_t, uint8_t) offset:2302 data:00
void vme_fcscsi1_card_device::write8(offs_t, uint8_t) offset:2303 data:00
Because I can
|
|
|
|
|
Joined: Mar 2001
Posts: 17,008 Likes: 94
Very Senior Member
|
|
Very Senior Member
Joined: Mar 2001
Posts: 17,008 Likes: 94 |
Yeah, the memory system can do a lot for you in terms of bus sizing and things like that. It's great.
|
|
|
|
|
Joined: Jun 2001
Posts: 503 Likes: 20
Senior Member
|
Senior Member
Joined: Jun 2001
Posts: 503 Likes: 20 |
Yeah, at this point most of what makes sense can be written relatively easily and just works unsurprisingly. It's not perfect, the abstraction is still leaking in places, but I kinda like it still.
|
|
|
|
|
Joined: May 2005
Posts: 50 Likes: 39
Member
|
|
Member
Joined: May 2005
Posts: 50 Likes: 39 |
It looks like we might be duplicating our effort, or at least making changes to the same stuff. I’ve been working on rewriting the VME signal handling and I’ve got my 120, 050, and 320 talking to each other, probably at the cost of breaking all the other cards. I’ve been keeping a separate branch since I don’t want to put in a PR until I’ve got the 320 able to read disks. Let me fix up my changes and I’ll link what I’ve got so far.
Last edited by Luigi30; 12/24/21 04:09 PM.
|
|
|
|
|
Joined: May 2005
Posts: 50 Likes: 39
Member
|
|
Member
Joined: May 2005
Posts: 50 Likes: 39 |
|
|
|
|
|
Joined: Aug 2015
Posts: 405
Senior Member
|
|
OP
Senior Member
Joined: Aug 2015
Posts: 405 |
Great, I'd love to have DTACK support on the VME bus. I can probably cherry-pick vme.cpp and vme.h to my branch so we stay in sync
Because I can
|
|
|
|
Forums9
Topics9,189
Posts120,338
Members5,044
| |
Most Online1,283
Dec 21st, 2022
|
|
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!
|
|
|
|
