Minor Z80 changes

[jackokring]

• IM 2 mode uses a fixed data_on_bus of 0xff and uses (i<<8+0xff) Indirect for both bytes of the vector. Saves 256 bytes for possible demos without not working with IM 2 software (mainly games).
• Made IM 0 a ED 46 prefix for own use (IM 0 mode is useless on the ZX Spectrum as /INTACK is not available on the rear socket for breakpoint hardware). Makes for an easy experimentation ground to add instructions.

[fruit-bat]

Thanks you for the suggested changes. I'm afraid they cause problems with some programs; I'm not sure why yet. The pull request contains code and documents relating to the Jupiter Ace. Is this part of a conversion to a Jupiter Ace emulator?

[jackokring]

Supposedly the data bus is pulled high when nothing is driving it. So only the value 0xff is ever used. But some "cheap" add-ons used pulldown even when the bus was in interrupt acknowledge so making a guaranteed 0xff impossible for "sale" of a working game. I've altered the vector to be 2 bytes because of a fixed vectoring assumption (no "cheap" ill-designed hardware connected).

I've removed the forth stuff except for the .asm file I'm going to convert to spectrum IO routines while not having to reimplement most of a forth from. I expect the hardest part to be reading the screen buffer and something like SCREEN$ will be needed. I can remove all the tape routines as I'd not expect them to be useful in a .z80 file save world.

[jackokring]

The AY driver has a _reg[16] and yet _reg[255] would be allowed by z80 code into the data structures of the emulator. Not technically a major in context, but an upstream might be required for other uses of the AY.

[badrianiulian]

I can remove all the tape routines as I'd not expect them to be useful in a .z80 file save world

I am sure there are still a lot of tapes out there that are waiting to be dumped... I know I used to have some old projects on some tapes that could make it into the now days by using this project, and I'm sure I'm not the only one. Improvement I can understand... but to take out something that made history... I'm not so sure it's a good idea.

[jackokring]

I've planned some coding for tomorrow. I might just use the spare ay3 register pair as a counter. And pin 16 could be a sync from IRQ. I've rationalised some of the coding ideas to maximize the compatibility. The DVI code is quite difficult to think about how I might beam chase or float and wait for attributes on the bus. But a 256*168 eight colour mode might be quite an easy do.

[jackokring]

Remove the tape routines from the ROM, or more specifically the ROM I'm intending to also code. Still got to think about that one.

[jackokring]

Ok, much done, so little to show. A port which connects to nothing but "saves" and "loads" (only for the IM 3 future mode) with expected weirdness if used in regular 128k mode (no save but usable until interrupt mode changes). A replacement for the 128 MIDI/KEY port thing by an IRQ synced audio 230 microseconds clocked counter, just more useful than some bit bang serial.

[jackokring]

OK, DVI checks need to be done by an owner of a DVI setup. The VGA one is like basic masking of know colour things, DVI is a plane order. BRG order assumed, likely wrong.

OK. Today was an ok day ...

[fruit-bat]

You may need to pull pico-emu-utils, if you haven't already. Small joystick fix went in yesterday.

[fruit-bat]

Ok, so I am not quite sure what you are creating, but I have been enjoying looking through the commits. Sorry if my last commit stamped on your changes 🙁. Actually disappointed to see this one close! Is your assembler working now? It looks good enough for it's own repo!

[jackokring]

So it appears a branch and merge conflict happened and it resets pull requests. The port read/writeIO...

Fixed. Added some xtra instructions to the z80 and almost ready to test the assembler.