github/SVC16
1
1
Fork 0
mirror of https://github.com/JanNeuendorf/SVC16.git synced 2025-06-04 18:45:27 +00:00
Code Issues Packages Projects Releases Wiki Activity

Used more consistent wording and added expandability to the goals. Added more examples for expansions.

Browse Source
This commit is contained in:
JanNeuendorf 2024-12-21 12:50:39 +01:00
parent 336403928f
commit 27e8575025
1 changed files with 16 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
specification/specification.typ
View File

@ -47,6 +47,12 @@ This means there can be no features that might only available in one implementat
It also means, that the performance characteristics must be the same.
An emulator can either run the system at the intended speed, or it can not.
== Expandability
This might seem at odds with the previous goal.
But if adding a new feature always requires changing the specification, that either means that supporting any new feature means breaking all compatibility, or it means that any expansions are ruled out forever. The compromise is that the behavior for the computer itself is fixed and we define an interface and rules for expansions that can be emulated together with the computer.
The Idea is that it is always to know this specification and one specification (if any) for the expansion.
= General Principles
@ -221,26 +227,29 @@ Its second function is to communicate with the expansion port.
The goal is to provide a mechanism for someone to add additional functionality to their emulator without making it completely incompatible.
This we call the expansion card.
The mechanism works as follows:
If the expansion port is triggered with the *Sync* instruction, it writes out the full utility buffer through the virtual port, making it available for the extension card to read. It is then replaced by $2^16$ new values provided by the extension. From the programs perspective, this is an atomic operation. It triggers the mechanism with the *Sync* instruction and when it gets to run again, the whole buffer has been exchanged. This is supposed to model a transfer of data between the program and the virtual extension card.
If the expansion port is triggered with the *Sync* instruction, it writes out the full utility buffer through the virtual port, making it available for the expansion card to read. It is then replaced by $2^16$ new values provided by the expansion. From the programs perspective, this is an atomic operation. It triggers the mechanism with the *Sync* instruction and when it gets to run again, the whole buffer has been exchanged. This is supposed to model a transfer of data between the program and the virtual expansion card.
It should follow the following rules:
- The data coming in can not depend on the data being flushed out this frame. It can be influenced by previous transfers, but it can not run computations during a transfer.
- The expansion card does not get access to any other information internal to the system (screen buffer, memory or instruction pointer). It can not manipulate these components either.
- It can not manipulate the utility buffer at any point where the mechanism was not explicitly envoked.
- It can not see or mainipulate what is on the screen or what input is being passed to the system.
- It can not manipulate the utility buffer at any point where the mechanism was not explicitly activated.
- It can not see or manipulate what is on the screen or what input is being passed to the system.
- It can not change any rule of the emulation.
Synchronizations that are caused by exceeding the instruction limit never trigger the expansion mechanism.
Synchronizations that are caused by exceeding the instruction limit never trigger the expansion mechanism. The expansion card can not know that such a synchronization happened.
If no extension card is available, there is no answer when the exchange is triggered. As a result the utility buffer is simply cleared.
Here are some examples of what an extension card might do:
If no expansion card is available, there is no answer when the exchange is triggered. As a result the utility buffer is simply cleared.
Here are some examples of what an expansion card might do:
- Play an audio sample.
- Provide keyboard or other text input.
- Perform some computation on the input and report back the result the next time it is activated.
- Access some emulated file system.
- Connect two SVC16 systems.
The mechanism is intentionally designed to allow for emulators that mimic _swapping the expansion card at runtime_.
The system itself has no mechanism to know with which expansion (if any) it is being emulated at any given time, so in addition to changing the expansion externally this change would need to be communicated to the program.
= Example Program