Previous Thread
Next Thread
Print Thread
Page 18 of 19 1 2 16 17 18 19
Luigi30 #120227 12/25/21 10:20 AM
Joined: Aug 2015
Posts: 405
Edstrom Offline OP
Senior Member
OP Offline
Senior Member
Joined: Aug 2015
Posts: 405
Originally Posted by Luigi30
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.
All cards so far has used the address space of the CPU board with no VME bus signaling involved and I am trying to create a bus address space to accommodate many to many relations, eg if you have two CPU cards that wants a single I/O board or in some rare cases a single CPU board do single write to multiple boards etc.

Let's review the best approach, I don't think there is much to break yet but we'll see.


Because I can
Edstrom #120228 12/25/21 06:26 PM
Joined: May 2005
Posts: 40
Likes: 5
L
Member
Offline
Member
L
Joined: May 2005
Posts: 40
Likes: 5
Yeah, I don’t have bus arbitration yet but I have /DTACK and a couple other signals. The ‘320 and ‘120 are both capable of bus mastering under my vme.cpp. A card can assert a signal line which gets distributed to all attached cards on the backplane as a callback for them to override (or ignore if they don’t care).

The way I have it set up is using install_device to insert handlers into the VME A24 address space, then having a memory handler on each card to perform read/write operations to A24 when they call out to VME. I don’t have all the signal logic going yet for that but it works well enough to let 120bug interact with the 320 via its standard monitor commands and for the 120 to detect the 050 during boot. Being able to overlay memory regions and handlers is very helpful.

The 120 does fail its self test and I’m not sure why, it seems to be something with the 68000 core I haven’t worked out. I added a two-byte ROM hack to the driver to get it to pass where it locks up so I can at least get to a console.

Last edited by Luigi30; 12/25/21 06:28 PM.
Luigi30 #120229 12/25/21 07:50 PM
Joined: Aug 2015
Posts: 405
Edstrom Offline OP
Senior Member
OP Offline
Senior Member
Joined: Aug 2015
Posts: 405
Originally Posted by Luigi30
Yeah, I don’t have bus arbitration yet but I have /DTACK and a couple other signals. The ‘320 and ‘120 are both capable of bus mastering under my vme.cpp. A card can assert a signal line which gets distributed to all attached cards on the backplane as a callback for them to override (or ignore if they don’t care).

Cool, I think the challenge with DTACK is how to suspend the CPU board until you'll get the DTACK in a good way, especially as the M68000 core didn't have DTACK support last time I checked at least, so emulate that by eating cycles. Also it is a good thing to put common stuff in the VME device and just parameterize it. Often DTACK has different timing for each device on a board so the DTACK value should really be property on the memory map but I am unsure if any VME boards had split DTACK values or just had one for its entire VME window.

Quote
The way I have it set up is using install_device to insert handlers into the VME A24 address space,

As long as it is possible to use either the maincpu address map or the VME bus device address map through the use_owner_spaces() I am good with that as it ensures simpler driver code for the SBC case, without a "physical" VME chassi, or just one slot, mainly supplying DC power and GND, I have done something similar but if you have wrapped your head around a good way to do it I can adapt.

Quote
then having a memory handler on each card to perform read/write operations to A24 when they call out to VME. I don’t have all the signal logic going yet for that but it works well enough to let 120bug interact with the 320 via its standard monitor commands and for the 120 to detect the 050 during boot. Being able to overlay memory regions and handlers is very helpful.

Sounds useful, will read up on that.

Quote
The 120 does fail its self test and I’m not sure why, it seems to be something with the 68000 core I haven’t worked out. I added a two-byte ROM hack to the driver to get it to pass where it locks up so I can at least get to a console.

Many MAME systems do have problems with self tests and it can be for various reasons but timing is a difficult one when not having proper DTACK support in the CPU core. ROM hacks are not ok to submit I believe unless you do it live, that is having a proper ROM and patch it during startup, many systems seems to do that.


Because I can
Edstrom #120230 12/25/21 08:49 PM
Joined: May 2005
Posts: 40
Likes: 5
L
Member
Offline
Member
L
Joined: May 2005
Posts: 40
Likes: 5
Originally Posted by Edstrom
Originally Posted by Luigi30
Yeah, I don’t have bus arbitration yet but I have /DTACK and a couple other signals. The ‘320 and ‘120 are both capable of bus mastering under my vme.cpp. A card can assert a signal line which gets distributed to all attached cards on the backplane as a callback for them to override (or ignore if they don’t care).

Cool, I think the challenge with DTACK is how to suspend the CPU board until you'll get the DTACK in a good way, especially as the M68000 core didn't have DTACK support last time I checked at least, so emulate that by eating cycles. Also it is a good thing to put common stuff in the VME device and just parameterize it. Often DTACK has different timing for each device on a board so the DTACK value should really be property on the memory map but I am unsure if any VME boards had split DTACK values or just had one for its entire VME window.

Right, the way I have it set up is that the 120 will halt waiting for DTACK until it either times out (the board will pulse BERR if the bus cycle isn't complete after 220ns) or it's asserted on the bus. There's a bunch of logic on the 120 to figure out which DTACK we're waiting for but at the moment it only cares about the one from the bus. I have the halt set up using a timer/spin_until_trigger combo.

Originally Posted by Edstrom
Many MAME systems do have problems with self tests and it can be for various reasons but timing is a difficult one when not having proper DTACK support in the CPU core. ROM hacks are not ok to submit I believe unless you do it live, that is having a proper ROM and patch it during startup, many systems seems to do that.

Right, it patches live during startup to bypass one specific test (replacing a branch with a NOP like all good hacks).

Last edited by Luigi30; 12/25/21 09:02 PM.
Edstrom #120242 12/28/21 10:38 PM
Joined: May 2005
Posts: 40
Likes: 5
L
Member
Offline
Member
L
Joined: May 2005
Posts: 40
Likes: 5
I figured out that emulating the ‘320 properly has to be so low level that the whole emulator is slowed down unacceptably, so I’m working on an HLE version based on the hardware instead. I can’t seem to figure out the new floppy subsystem though. What device should I look at for a good example of reading an MFM image? I’ve been copying from one of the other Motorola controller drivers but can’t work out how the PLL stuff works.

Edstrom #120243 12/29/21 01:59 AM
Joined: May 2005
Posts: 40
Likes: 5
L
Member
Offline
Member
L
Joined: May 2005
Posts: 40
Likes: 5
Specifically, here's the live_run function that I don't know how to set up. It looks like all the data is shifted by one bit, (instead of $FF followed by six bytes of $00 as a sync gap in the sector, I get $F8 $07 $00 $00 $00 $00 $00...) so I'm not synced properly? How do I adjust that to the image's clock?

Edstrom #120244 12/29/21 02:22 AM
Joined: Mar 2001
Posts: 16,892
Likes: 51
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,892
Likes: 51
Maybe emulate it properly anyway, and then profile to see if there's perf wins you can pick up? In the long run you're always ahead to emulate things correctly up front.

Edstrom #120246 12/29/21 04:34 AM
Joined: May 2005
Posts: 40
Likes: 5
L
Member
Offline
Member
L
Joined: May 2005
Posts: 40
Likes: 5
I'll need to know how to sync the PLL either way!

When I started, I didn't realize the board did things like stretch the clock phases to match the processor speed with the floppy data rate. I reverse-engineered parts of the firmware and made the 8X305 core subcycle-accurate to get it this far, but this is far, far above my experience level. I'm a programmer, not an analog hardware guru. frown

I don't want to leave it as-is but I haven't been able to make substantial progress on emulating the PLL and the other microcoded subsystem clocked by it that actually interact with the floppy drive.

Last edited by Luigi30; 12/29/21 04:37 AM.
Luigi30 #120265 12/30/21 03:10 PM
Joined: Aug 2015
Posts: 405
Edstrom Offline OP
Senior Member
OP Offline
Senior Member
Joined: Aug 2015
Posts: 405
This has happened to me many times too, it has been either that emulation is not as far advanced in MAME yet or simply that it has been too slow for mainstream PC:s. I used to get very frustrated over this but has came to conclusion it is much better to document what has been done and either go HLE for that part or wait for MAME and/or PC:s to catch up.

Storage media has always been problematic and no one ever loved magnetic media so I think the general conclusion is that it is ok to convert to a generic formats using external tools and load it on a (slightly) higher level to avoid the PLL level, if it is possible. Eventually someone rewrites/improves MAME:s scheduler or whatever is causing the problem and it will be possible to do the LLE.

Originally Posted by Luigi30
I don't want to leave it as-is but I haven't been able to make substantial progress on emulating the PLL and the other microcoded subsystem clocked by it that actually interact with the floppy drive.


Because I can
Edstrom #120271 12/30/21 04:56 PM
Joined: Mar 2001
Posts: 16,892
Likes: 51
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,892
Likes: 51
You can absolutely do cycle-accurate full system emulation in MAME now, but you need to start from a cycle-by-cycle capable CPU core (one that can run only one cycle of an instruction rather than always running at least 1 instruction).

Page 18 of 19 1 2 16 17 18 19

Link Copied to Clipboard
Who's Online Now
2 members (Xolod, 1 invisible), 21 guests, and 2 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,070
Posts118,941
Members5,014
Most Online890
Jan 17th, 2020
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com