Home Page Forums MAME MAME Requirements?

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

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

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

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

Thanks for all ideas & suggesstions so far!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Will we get away without it?

OMG...i am talking to myself

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

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

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

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

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

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

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

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

lines 145-147

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

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



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

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



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

Thanks
Robert