Converting Sinclair Basic to CP/M

[cj7hawk]

Hi All,

At the moment, I'm converting the ZX Spectrum ROM to a CP/M .COM executable to run Sinclair Basic from the command line.

I'm part way there, though not very far yet. I have it executing without requiring interrupts using the BDOS for video and keyboard, with several features operating correctly, while keeping shy of the BDOS and once I have the functions working correctly, I'll start working on adding in file and disk support within the standard command set.

I've gotten the cursor up, have it running in 80 columns+ ( it looks pretty nice in 80 columns compared to the cramped 32 column Spectrum screen ) and I'm working on building a series of objectives to allow it to do more, eg, have variable screen resolutions - (eg, 20,32,40,56,64,80,128 column displays ) and also support graphics protocols to deliver the commands it already has there. I'm planning on converting as much of it as possible to support ADM-3A and RG-512 format and also to make it work under emulation on Windows 10/11 from CLI.

I plan to remove old redundant code (eg, fixed-memory video support ) and it loads into the normal TPA at $100, though it does hook the RSTs so as to drive it's own functions - RST38 isn't used though, and neither is NMI since it can run entirely with interrupts disabled now.

It's currently a little smaller than the typical 16K footprint and my goal is to achieve the same program size capability as a ZX Spectrum can handle, while maintaining the BDOS and BIOS and respecting the zero page. I can recover the unused memory, and also the character rom code, as well as some of the print and input routines as I've replaced them already.

I'm also looking at ways to integrate CLI parsing so that when a command is typed in, eg p-r-i-n-t - it will hit the error and change it out for the F5 token "print". This presently extends to editing, which will fill the command line with the spelled command rather than the token, though I'm not sure of the best way to do this, but I want to support both fast-token generation and typing in keywords, while supporting both simultaneously, including mixing them.

I was wondering what other changes I should make while I'm at it, and what people would want to see in a CP/M supported version of ZX Spectrum Basic. So far, I'm thinking to make SAVE and LOAD work directly with the disk system via the BDOS, but don't want to go too far or use overlays, as the interpreter really should work standalone like most basics. Making CAT work as a DIR is an obviously needed capability, and FORMAT can be used to change external settings or do something else (eg, screen resolutions in software ) while i suppose copy could, well, copy files, though at 128 bytes at a time, it isn't going to be blisteringly fast for that kind of activity. Though I don't really need to support OS functions from the CLI since it's a *CP/M* system and those functions are more or less available from the host OS.

So what would other Sinclair fans want to see if ZX Spectrum BASIC programs ran on CP/M machines?

Thanks
David

 

[cj7hawk]

I should add, this is a rewrite and update of the existing 48K ROM - I'm not writing a completely new BASIC program that is "Sinclair" compatible. So I'm keeping as much of the functional code from the original as possible.

 

[MiaM]

Re typing:
Maybe look into the Basic for the later Spectrums, that allowed typing in commands verbatim rather than mandating using the shortcuts.

Sorry if this is obvious but it might be a good idea to keep as much of the code at the same locations as in the standard Spectrum ROM, as that might make it more compatible with existing software.

Re video memory and whatnot: Maybe consider doing a version for computers that have build in video hardware, and adapt it to different versions of how this works. Or maybe not? I assume there are very few if any other computer that has a fully spectrum compatible video memory layout.

 

[rodney]

Hi David,

That is an amazing and cool project, I love it!

I imagine it will be a lot of work to realize this, however well worth the effort in my opinion, you are creating something new and unique.

Possibly your work will also inspire new ideas for doing something similar like having some Sinclair video circuits available on a CP/M capable computer after a CP/M boot and being able to realize the CP/M console using the Sinclair display and Sinclair keyboard which together could form a CP/M compatible console I/O device.

These kind of creative ideas could potentially spark many exciting things to follow!

I applaud your programming expertise to take on such a project as this, and wish you all the success with your work!

Kind regards,

Rodney

 

[cj7hawk]

Re typing:
Maybe look into the Basic for the later Spectrums, that allowed typing in commands verbatim rather than mandating using the shortcuts.

Sorry if this is obvious but it might be a good idea to keep as much of the code at the same locations as in the standard Spectrum ROM, as that might make it more compatible with existing software.

Re video memory and whatnot: Maybe consider doing a version for computers that have build in video hardware, and adapt it to different versions of how this works. Or maybe not? I assume there are very few if any other computer that has a fully spectrum compatible video memory layout.

Yes, I liked that on my 128/+2/2A/3A I can type in commands, but they never created a single combined BIOS, rather they created a new "compatible" basic and left the old one in as an option.

Fortunately, Amstrad has permitted open copying and modifications to both the original, enhanced and Amstrad updated versions of Sinclair BASIC, as long as they are distributed without charging, though I don't think anyone has rewritten the Sinclair BASIC before to port it to another platform entirely.

I discovered it has a lot of great stuff in it already - for example, as long as you ignore what machine code programs did, you can use the API to read the keyboard and it fully supports extended and expanded keyboards beyond the original 8x5 matrix, including all the missing ASCII characters it doesn't support, and you don't need to use key combinations to achieve extended mode, delete, arrow functions or other control keys - they can just be single keys - unfortunately, they locked the vectors to change this easily into the ROM, but they did think far enough ahead that you can add them into a channel, which uses chained vectors in RAM space once it's running, so it's possible to write very small drivers that revector the channels and streams and allow you to have your own keyboard routines for working in basic while fully supporting the default keyboard matrix. It's entirely extendable.

For those unfamiliar with Sinclair BASIC, they did design in an API to read keys, send information to the screen, use the floating point calculator and access other critical routines - it just was very poorly understood in the era of the ZX Spectrum, so almost no one used it, mainly because they didn't understand why it existed at all, and it didn't allow continued monitoring of a keypress, or facilitate graphics, but it was accessed via the RSTs.

Anyway, originally, I made a "serial" keyboard work by rehooking the vectors, but that messes with the channels, and that prevents the R channel from working, and then you can't use the Sinclair code editor, so I shifted the keyboard and display routines to the channel call table stored in the startup code. Doing this means you can type keys that don't exist in the Spectrum ROM and it recognizes them - eg, you can have all three brackets on keys ({[]}) and the ROM accepts them. You can even have a copyright key, a dollar key and a pound key that sit entirely outside of the matrix.

Also, once you do this, you are also no longer constrained by the code that creates tokens, and you can both type in symbols and keywords directly, bypassing the original Sinclair syntax - but the inbuilt BASIC doesn't know how to parse the keywords if typed in. You can also modify the point at which symbols are recognized, and then if you "edit" a line, it types out the symbols by key, though again, the editor will just error when you go to re-enter the line, so a hook of RST08 is needed to kick off a parser to search for potential valid symbols, but it is aware of what mode is being selected so it has a clue as to what symbol might be correct for any error generated and this can be an automated re-iterative approach - eg, if syntax error, check if the current error should be converted to a symbol.

This is a much nicer approach than the 128 IMO, since it blends both the original keyboard code and extended code.

I have a version that maintains the original routine locations, and a version that ignores them and is more efficient space-wise. Even at the cost of stopping external code from accessing well known routine locations, it seems better to go for reduced memory size of the BASIC to keep it under 16K and to reuse the screen memory as TPA.

 

[cj7hawk]

Hi David,

That is an amazing and cool project, I love it!

I imagine it will be a lot of work to realize this, however well worth the effort in my opinion, you are creating something new and unique.

Possibly your work will also inspire new ideas for doing something similar like having some Sinclair video circuits available on a CP/M capable computer after a CP/M boot and being able to realize the CP/M console using the Sinclair display and Sinclair keyboard which together could form a CP/M compatible console I/O device.

These kind of creative ideas could potentially spark many exciting things to follow!

I applaud your programming expertise to take on such a project as this, and wish you all the success with your work!

Kind regards,

Rodney

Thanks Rodney - I am doing that as I slowly rebuild the Sinclair Loki from original specs - it will probably be the first full Loki ever build. It's a long way from home though since the Loki was original intended to exist in 1985. I suppose that, as long as I keep the ROM under 16K in size, making a CP/M compatible ZX Spectrum would be entirely possible with a screen at $4000 though programs in the TPA would need to be aware of this, which is a problem - hence why I'm obscuring the video hardware from memory. At the moment, the new screen design (Loki mode) supports 512x192 at 16 colors and can be accessed entirely through I/O space. At some point I'll also integrate high resolution graphics into it at both 512x192 and 256x192x64 colors.

I am getting around compatibility problems by allowing use of an original spectrum as a "Screen and Keyboard" for the Loki - ie, plugs into the back of a real spectrum and runs CP/M on a Spectrum via the Loki, but also allows the extended Loki modes via it's own video hardware. So I suppose this is also a two-screen mode - eg, Loki screen and Spectrum screen connected and operating independently at the same time. That's also how I plan on getting tape programs to and from the Loki as well as supporting legacy hardware - eg, printers, microdrives. Or a completely new serial keyboard can be attached and it just works natively in Loki mode.

So far it's been very difficult having to work out how the ZX Spectrum ROM works. I had some knowledge, but going into the code in detail has been challenging. I can only thank those who produced some really good disassemblies for documenting it well, though it's still difficult to figure out how they did things, and several times I have to stop and map out the interactions between the code routines to achieve certain functions. Routines are also used from multiple locations which makes thinks more difficult to figure out.

 

[MiaM]

Yes, I liked that on my 128/+2/2A/3A I can type in commands, but they never created a single combined BIOS, rather they created a new "compatible" basic and left the old one in as an option.

Fortunately, Amstrad has permitted open copying and modifications to both the original, enhanced and Amstrad updated versions of Sinclair BASIC, as long as they are distributed without charging, though I don't think anyone has rewritten the Sinclair BASIC before to port it to another platform entirely.

I discovered it has a lot of great stuff in it already - for example, as long as you ignore what machine code programs did, you can use the API to read the keyboard and it fully supports extended and expanded keyboards beyond the original 8x5 matrix, including all the missing ASCII characters it doesn't support, and you don't need to use key combinations to achieve extended mode, delete, arrow functions or other control keys - they can just be single keys - unfortunately, they locked the vectors to change this easily into the ROM, but they did think far enough ahead that you can add them into a channel, which uses chained vectors in RAM space once it's running, so it's possible to write very small drivers that revector the channels and streams and allow you to have your own keyboard routines for working in basic while fully supporting the default keyboard matrix. It's entirely extendable.

Nice gesture by Amstrad!

Re matrix: This was at least known by someone back in the days. In particular the Sinclair importer in Sweden, Beckman, made a specific Nordic ROM (IIRC spelled Nordisk ROM, scandinavian spelling) that not only added the national characters, but also added support for additional keys. Combined with their "better keyboard" (that I think was a slightly modified version of one of those that was sold in the UK), you got extra keys for certain things (including the national characters).

 

[cj7hawk]

Nice gesture by Amstrad!

Re matrix: This was at least known by someone back in the days. In particular the Sinclair importer in Sweden, Beckman, made a specific Nordic ROM (IIRC spelled Nordisk ROM, scandinavian spelling) that not only added the national characters, but also added support for additional keys. Combined with their "better keyboard" (that I think was a slightly modified version of one of those that was sold in the UK), you got extra keys for certain things (including the national characters).

Is there a copy of that rom anywhere? I'm curious what parts they changed. Adjusting the character set is trivial and won't affect the general ROM behavior, but adding extra keys and key functions to the additional 40 requires additional hardware decode or increasing the scanned keys (eg, Scan 6 bits instead of 5 for a 48 key keyboard ) but this also necessitates adding more code to the rom to facilitate the support. I
m curious how they did it.

This is the only image I could find that seems similar but doesn't seem to have additional keys or characters.

 

[MiaM]

Seems like the ROM is archived here, with some description:

Sinclair ZX Spectrum Nordisk version – Sinclair Collection Site

www.sinclaircollection.site

I can't find any pictures of the keyboard.
Unfortunately my Spectrum with that keyboard is stored somewhere underneath-behind [tm] and it would take a while to dig it out from the hoard. I assume that the ROM code would give a hint about the hardware though.

If you feel like spending ages on it, maybe check the advertisements from Beckman in the Swedish magazines from around 1984 or so

Stonans Scanningar

 

[Starcat]

There a low res B&W photo of a ZX Spectrum in this 1984 issue of the Swedish magazine Allt om Hemdatorer:
https://archive.org/details/AlltOmHemdatorer19843/page/n27/mode/2up?view=theater

 

[cj7hawk]

@Starcat That also looks like a standard spectrum keyboard. I have a feeling MiaM has something a bit different to that.

 

[MiaM]

Yeah, this was an add-on keyboard.
(The case feels rather cheap, but also it's large enough to not only house the Spectrum but also an Interface 1, with a cable to a Microdrive poking out through a slot in the case. The Spectrum and an optional Interface 1 is screwed to the case, can't remember the exact details. A bus connector with through port is connected to a ribbon cable up to the actual keyboard).

 

[cj7hawk]

@MiaM I really want to see this keyboard if you ever do find it, but completely understand your situation since it happens to me also... though If you do come across it sometime, please post a picture.

OK, Update - I now have auto-tokenisation working at least as far as the first token it hits. It can't do the second token, because every time I fix the first token, it breaks it again when the editor detokenizes it, then fixes it again, and so constantly keeps going back to the first token. But I knew that was going to happen since I de-encapsulate the tokens when I print them. That's a bug I have to chase elsewhere...

But still, it was nice to type 10 print "Hello World" and it converted it automatically to 10 [F5] "Hello World" then I typed RUN and it errored once as it converted R-U-N to "RUN" but it worked, and printed "Hello World".

This is MUCH nicer than how the 128K spectrum basic worked. It's still 48K basic, but allows typing in the full command, and it didn't take much extra code - it would have easily fitted inside the original Spectrum ROM. In fact, it would even fit in there without the rest of what I'm doing. Also, it's possible to use key combinations to just hit "P" and make "PRINT" come up just like an original 48K.

Now I just need to shift the point at which the tokens are converted back to strings a few levels closer to the output routines, and work out how to force a carriage return back to the edit function, and I can auto-tokenize a full line... At least I think I can. (There's room for error until I do it... )

 

[Starcat]

@Starcat That also looks like a standard spectrum keyboard. I have a feeling MiaM has something a bit different to that.

Yeah, I didn't zoom in close enough on that image.

Yeah, this was an add-on keyboard.
(The case feels rather cheap, but also it's large enough to not only house the Spectrum but also an Interface 1, with a cable to a Microdrive poking out through a slot in the case. The Spectrum and an optional Interface 1 is screwed to the case, can't remember the exact details. A bus connector with through port is connected to a ribbon cable up to the actual keyboard).

Got it. That sounds like the Beckman 2000:
https://archive.org/details/PersonDatorn84-8/page/n73/mode/2up?view=theater

 

[cj7hawk]

For some reason, archive.org is very very slow lately - painfully slow. It's OK once I make a connection, but is absolutely a dog before that... Anyone else noticing that ?

Anyway, command line parsing now works - eg, I can just type in text, and as it causes errors, the system automatically attempts to convert the errors to tokens, and it works... Learned a lot about what system variables are critical to that process. seems the spectrum uses lots of markers between memory areas, but it doesn't use them. Instead it uses system variables. Oh well, more stuff to fix later.

Anyway, its' interesting. As the CLI parses, it highlights errors, and if I hit enter, it attempts to convert them to tokens, and if successful, it updates them and moves on. If not successful, it just stays stuck on the command that is causing the issue - eg, if I do something like 10 for a = 1 to 100 first it stops on the FOR and then next on the TO. If I hit enter when it asks me, it tokenizes them both. It's still possible to just keyword them and bypass the tokenization, like a normal spectrum, but it's cool being able to just type in the keyboards manually and it still recognizes them as valid code. I might find a way to fast-track it if I'm in an edit pass, but so far I haven't had to add any new system variables, and would like to minimize any I add.

Next I suppose I need to make saving and loading from disk possible, so when I write a program, I can save it and reload it later.

David.

 

[cj7hawk]

OK, just saw the Beckman 2000 - that looks like a normal keyboard expansion also - though might support some remapping of specific characters via the bitmaps and with a different graphic on the key.

But some keys, like Tilde, still require a minimum of two keypresses. One to get into extended mode, and one (with symbol shift) to press A to get the key. It's mapped through a process.

What I'm talking about is a single key process where there *is* no extended mode - and all the missing keys ( ie, ASCII characters for which there are no key ) including the "User Defined" graphics areas, can all be added with single keys. You can still get things like extended-mode-symbol-A to work potentially, but I am removing extended mode entirely - it will be replaced with instant "Extended Shift" keys - so a single operation and a single key read.

Also, it's possible to support type-ahead and input key buffering so that you don't have to wait for the computer to respond when you have a big basic program installed. You can just type ahead and it will keep going.

Editing is working just like on a ZX spectrum, though I need to make some changes to how the lower/upper screen split is recognized, and the ZX Cursors work rather than relying on the terminal cursor. Well, they work in ADM-3A mode - you do need attributes on the terminal to support them.

So far, it's pretty good. Now I can type things in, I'm not bothering with the extended shift or other shortcuts. Actually, I'm not sure if extended mode works at all with the changes I've made today since I don't have that many shift keys on a PC Keyboard... But the primary one-shot command keys all work normally. And I'm using the cursor pad keys for different functions - eg, EDIT.

This is feeling pretty nice for a Spectrum. I just finished typing in a 10 line program fully from single keys and it worked ! I still have a lot to do, but this is a major success.

David

 

[MiaM]

Yes, Beckman 2000 is the model I have, thanks!

I'm 99.9999% sure that you need the "Nordisk ROM" to be able to use the additional keys. I.E. those are decoded as extra keys, not within the standard matrix.
I assume that this is just a version of some keyboard that was sold elsewhere, likely in the UK? Would be nice to know which it was, if so.
The hardware that sits between the Spectrum and any external expansions (or between the Interface 1 and any external expansions) is a rectangular metal thing IIRC. That part could had been custom for Beckman though as the PCB would likely anyways had been custom to support a larger matrix.


Btw how are you doing input/output?
I.E. are you doing a simple line editor that only supports backspace?

The perhaps coolest but perhaps also somewhat cumbersome would be to replicate the Sinclair editor but using terminal commands for cursor movement and whatnot.

How does Sinclair Basic store what you are entering? I.E. does it keep a line as tokenized bytes as an editor buffer in addition to the rendered characters on screen? If so it would seem easy to just keep that code, but instead of rendering on screen obviously send the characters as text to the terminal.

Thinking about it, I can't think of any other Z80 computer that always runs the video display in bitmap mode. The only computer I can think of where a port of Sinclair Basic would be less an effort than any else would likely be the Commodore 128 with it's Z80 and using the 40 col (C64 compatible) video hardware. The resolution is 320x200 rather than 256x200, but in bitmap mode it stores full bytes with four bits for foreground and four for background like I think the Spectrum does. The memory map probably differs too, and also the Z80 runs slower due to it being a Z80 squashed on to a 6502 bus.

Going off on two tangents:
Thinking about it, it might had been possible to create a C64 cartridge with a Z80 processor with extra logic that remaps the memory layout so from the Z80 perspective the C64 bitmap screen looks like the screen on a ZX Spectrum, and also 16k of memory would be write protected. It would "only" require a rewrite of the cassette and keyboard code to become semi-compatible with a real Spectrum. For some additional keyboard compatibility you'd want to convert one input operation to a write and a read to the row/column registers using some hardware trick, and to be compatible with joysticks I think the easiest would had been to just have a Kempston compatible joystick port on the interface. You could also have hardware that switches processor when interrupts occur, and have 6502 code read and convert keyboard and joystick input and put it in some memory space otherwise not used.
It would had been way slower than a real spectrum unless you'd fit it with it's own memory (but then there isn't much reason for making it an add-on to another computer, kind of sort of), but still.

The more off-topic tangent, but still relevant to vintage computing:
I've been thinking about something similar but for emulating an Apple II on a C64. A separate 6502 processor in a cartridge, with hardware that remaps the memory layout to make the C64 video hardware appear like the Apple II video hardware memory map to the 6502 processor. Again some interrupt code that runs on the built in 6510 could scan the keyboard and convert it to data compatible with the Apple II. Some part of the C64 memory could appear as an Apple II add-on card, containing what's required to use Commodore disk drives.

 

[cj7hawk]

Yes, Beckman 2000 is the model I have, thanks!

I'm 99.9999% sure that you need the "Nordisk ROM" to be able to use the additional keys. I.E. those are decoded as extra keys, not within the standard matrix.
I assume that this is just a version of some keyboard that was sold elsewhere, likely in the UK? Would be nice to know which it was, if so.
The hardware that sits between the Spectrum and any external expansions (or between the Interface 1 and any external expansions) is a rectangular metal thing IIRC. That part could had been custom for Beckman though as the PCB would likely anyways had been custom to support a larger matrix.

I doubt it. If they were extra-matrix, then they are indeed extra keys - so I'd love to know more. They might work the same as a joystick, or perhaps an extended keyboard matrix, though this is less likely as the 8x5 connectors on the motherboard don't permit it, so it probably has some hardware that sits on the external interface. You can wire up the entire keyboard via the external interface too, it's not a lot of extra circuitry as far as keyboards go.

Btw how are you doing input/output?
I.E. are you doing a simple line editor that only supports backspace?

It supports the full line editor for lines up to 85 characters. After that it still works, but scrolls frequently. I will have to adapt the keyboard a little more for that, and will need to extend the use of the ADM-3A capabilities a little perhaps, though want to make as much work with the standard terminal as possible. There is left/right arrows ( they work ) and up/down arrows (select line to edit ) and there is only "DELETE" which backspaces and deletes, and backspace, which doesn't delete. It's fairly limited but suitable for editing a single line.

The 48K keyboard runs from interrupts, views the modes in the OS, and provides key codes (ASCII mostly) for the appropriate key... So it doesn't send "P" when you want to print - it sends $F5 which is "PRINT" - when it sees a K cursor. You need the L cursor to type letters on a normal keyboard. I have both the K and L ( they are inverted - black on white ) so it feels very sinclair.

The Read routine works outside of the interrupts, and looks for flags that a character is available, then reads it from the system variable LASTK. It scans and moves on, unlike CP/M, but I don't need to move on - I can have it wait there for a key, since it's scanning for one anyway. I can also return that no key is available so functions like INKEY$ work. It depends on where it's called from.

So I hook the channel where it picks up the keyboard and drive it to a BDOS routine that uses direct console access and returns the correct key.

Same for screen - I intercept where it writes to the video memory, and redirect the codes out via the BDOS Printing routines.

It works amazingly well, and is testamount to how well the BASIC was written

The perhaps coolest but perhaps also somewhat cumbersome would be to replicate the Sinclair editor but using terminal commands for cursor movement and whatnot.

It works pretty well actually, Editing was always a problem in BASIC, so it's no worse than others, and given how I've adapted it, I'm still using the original editing routines without changes. They work well. OK, some modification, as obviously I intercept the errors and use them as a chance to tokenize the line.

How does Sinclair Basic store what you are entering? I.E. does it keep a line as tokenized bytes as an editor buffer in addition to the rendered characters on screen? If so it would seem easy to just keep that code, but instead of rendering on screen obviously send the characters as text to the terminal.

The screen is only a terminal on the Sinclair ZX Spectrum. I know it appears like they are using it for more, but when you think about how the screen is drawn, it becomes more apparent that the Sinclair Basic includes it's own independent terminal capability outside of the basic. In the program area, you get the program, the variables area and the edit-line, then the "WorkSpace" which is another word for "unused memory". As you type, you add characters into the E-Line which is terminated with a $0D, and the workspace is delineated by $80. But this is controlled by the editor and the inbuilt parser addresses variables, converts decimal to binary etc. Messing with that isn't possible without discarding the original BASIC, which I don't want to do. So I intercept the keyboard and screen channels and let the original routines do their thing. Working with them without breaking stuff is hard though...

Thinking about it, I can't think of any other Z80 computer that always runs the video display in bitmap mode. The only computer I can think of where a port of Sinclair Basic would be less an effort than any else would likely be the Commodore 128 with it's Z80 and using the 40 col (C64 compatible) video hardware. The resolution is 320x200 rather than 256x200, but in bitmap mode it stores full bytes with four bits for foreground and four for background like I think the Spectrum does. The memory map probably differs too, and also the Z80 runs slower due to it being a Z80 squashed on to a 6502 bus.

It's not that common a configuration, but now I've discovered how the "terminal" aspects of the zx spectrum work, it's a lot easier to understand. It's easy to see how the BASIC is a progression on other BASICs too.

Going off on two tangents:
Thinking about it, it might had been possible to create a C64 cartridge with a Z80 processor with extra logic that remaps the memory layout so from the Z80 perspective the C64 bitmap screen looks like the screen on a ZX Spectrum, and also 16k of memory would be write protected. It would "only" require a rewrite of the cassette and keyboard code to become semi-compatible with a real Spectrum. For some additional keyboard compatibility you'd want to convert one input operation to a write and a read to the row/column registers using some hardware trick, and to be compatible with joysticks I think the easiest would had been to just have a Kempston compatible joystick port on the interface. You could also have hardware that switches processor when interrupts occur, and have 6502 code read and convert keyboard and joystick input and put it in some memory space otherwise not used.
It would had been way slower than a real spectrum unless you'd fit it with it's own memory (but then there isn't much reason for making it an add-on to another computer, kind of sort of), but still.

I'll look at hardware compatability in other ways. The biggest hurdle in making a new CP/M version of the Spectrum is the keyboard hack - it's a nightmare to emulate even on an original Spectrum. But games didn't use the API - they scan directly. It's a real problem. Easier perhaps to change the way in which a spectrum is "Compatible" to save costs... Just like Sinclair would have done.

The more off-topic tangent, but still relevant to vintage computing:
I've been thinking about something similar but for emulating an Apple II on a C64. A separate 6502 processor in a cartridge, with hardware that remaps the memory layout to make the C64 video hardware appear like the Apple II video hardware memory map to the 6502 processor. Again some interrupt code that runs on the built in 6510 could scan the keyboard and convert it to data compatible with the Apple II. Some part of the C64 memory could appear as an Apple II add-on card, containing what's required to use Commodore disk drives.

Wow, you sure seem to love the C64. Well, they were probably the most popular home computer of the 80s. At some point, your C64 only becomes a keyboard, and the way the Spectrum uses the keyboard limits the value of adapting a C64 to be a "Spectrum" - though I'm not sure about the Apple. I still don't know a lot about how they work.

 

[rodney]

I am doing that as I slowly rebuild the Sinclair Loki from original specs

I am sure that this work though very complicated is ultimately going to be very rewarding David. I will try to find more information about this Loki computer.

I will definitely follow your work, it's really an interesting project!

Kind regards,

Rodney

 

[Starcat]

I don't know if this helps directly, but there are a few interesting tidbits in this magazine:
https://ia801509.us.archive.org/3/items/your-spectrum-magazine-01/YourSpectrum_01_Jan_1984.pdf

Page 24 mentions a program Master Key, which was able to define the SPACE key as a SHIFT key for user definable function keys and how it was impacted by hardware revisions.

Page 60 of the PDF describes how the registers and addressing works for keyboard scans.

Also, page 77 describes some of the system variables.

And lastly, page 42 has an ad for the Fuller FDS keyboard which was the one sold in the U.K.