The mame one actually needs another rewrite

Here's the schematics as promised (29MB greyscale PDF):
http://www.megaupload.com/?f=FE6G5WII
http://www.megaupload.com/?d=66O1EG9G (direct link in case folder view messes up)

The datasheets are all pretty bog standard and widely available, the idea was more for consolidation in one place than ensuring access.

Meh, looks from the mame code that HD46505SP-1 has absolutely no special features... I figured as much as I couldn't make anything but the basic geometry registers do anything.

What's the best way to display an interlaced field with this chip? Have a few long/short scanlines after vsync? Would a strategy like that work on newer LCD TV's and stuff like that?

Awright, well, I still might upload to MESS's online datasheet archive if they aren't already there, when I have time. http://mess.redump.net/datasheets

It really needed one since before we were forced to use it.

*wants a properly working CPC driver now*

Hey, what do you know, there's datasheets there now.

/hitachi/hd46505.pdf
/intel/1981_iapx_86_88_users_manual.pdf
/intel/8049h.pdf
/intel/8087.pdf
/intel/8088.pdf
/intel/8251a.pdf
/intel/8288.pdf
/mitsubishi/m5k4164anp.pdf
/mitsubishi/m5l2764k.pdf
/mitsubishi/m5l8251ap-5.pdf
/mitsubishi/m5l8253p-5.pdf
/mitsubishi/m5l8255ap-5.pdf
/mitsubishi/m5l8259ap.pdf
/mitsubishi/m5w1793-02p.pdf
/motorola/mc1488p.pdf
/motorola/mc1489p.pdf
/nec/upb6101.pdf
/texas_instruments/tms4416.pdf

except for the TTL stuff.

Thanks for the schematics, BradN!

I had another thought about the CPU<>memory bus... the schematic seems to suggest that the 3.58MHz clock cycles through 2 phases - CPU, CRTC, (in fact there is a signal line in the schematic that reflects this) but I had done some instruction timing measurements that suggest that single byte instructions (even prefixes) can execute no faster than 4 3.58MHz clocks (which made me think 1 cycle CPU, 3 cycles CRTC), and 2 byte instruction sequences no faster than 8 clocks each. But the schematic seems to suggest that the CPU should get the bus twice in 4 cycles, so perhaps some kind of single wait state is present on those cycles that it does have access?

This may make a little sense because some 2 byte instruction sequences took 10 cycles on average each, suggesting an effect either from instruction buffering or 2 cycle granularity in some way. I can't remember if I found single byte instructions that took 6 cycles average.

It kinda makes me wonder how much rewiring would be necessary to say, enable 2x speed bus during vsync and hsync? I suspect full non-display could be harder as bytes may be being buffered at the end?

A more practical mod might be wiring the keyboard's dtr through a spare inverter and to the single/double density select pin on the FDC... Instant apple ii 5.25" compatibility? Or is there a speed difference in those drives as well?

There's another extra general purpose input on the serial's input dsr (I believe, at least one of the status input pins), and an extra (slow) output in the highest address bit from the CRTC that some useful function could maybe be derived from. The 4th bit could be wired to the video page latch and used as another output. It doesn't take too many pins to make a SD/MMC interface...

And then, if you check out the audio output driver in the schematic, it almost seems like that setup might keep the transistor biased enough when the duty cycle is 11/12 high, at least for a while (12/12 would surely deplete the capacitor and shut off the transistor eventually). The transistor has a gain of at least 4000 supposedly so it should be rather forgiving.

I'm thinking about a low pass filter scheme where the motherboard's final output goes through a resistor, then split through a capacitor to VCC and 2 low forward voltage diodes in parallel with one backwards (such as to give a +-.2V or so wiggle room to cut out most of the remaining high frequency low amplitude noise), then maybe another capacitor(?) to VCC and the speaker. I'm having a hard time calculating out values that would be good for 6600Hz output while severely reducing higher frequencies though. I may have to experiment a bit.

Even outside the active display area the crtc is still driving the MAxx lines for memory refresh purposes. Technically the crtc is not accessing any ram; it is only generating the address lines used by the rest of the hardware for reading from ram and generating the display.

Apple II drives are GCR and are managed at a very low level by the host software - I doubt you could get them to do much useful on any sort of standard '765 or 17xx controller.

Ahh, I had no idea there were so many encoding schemes used on floppies. After looking up common formats, it looks like that hack would give instant Acorn compatibility, as there were few formats that used FM encoding at 300 RPM. Probably Atari disks at 288RPM would be readable, in addition because I believe the data rate on the Sanyo errs towards the high side by something like a percent or two. Not quite the same cool factor, but interesting nonetheless.

Cool, it's alive. I have a bunch of sanyo software which I am converting to disk images. Most of it works already.