Hello to all you avid readers :-)!
“Apparently” nothing much changed in Vide. If you just start “me”, everything looks the same, but under the hood quite a few changes were introduced.
- VecVox and VecVoice emulation reached a point where Malban said “that’s enough”. That sadly does not mean perfect emulation, but it means he can’t do more with the samples and DSP library he got. Malbans intentions never were to emulate the Speakjet chip (or the SPO256AL2 for that matter) fully – and using the available samples he reached his limit.
The vedi integration (and code generation) is finished (see last vide-diary entry), the generated code does produce speech on a real vectrex (with VecVox connected).
(BTW: Malban finaly did connect his AVox+ to the vectrex after torturing one of the bought cables…) - There were some “disturbances” with the DSP library Malban uses (Tarsos), since the sources are freely availably, Malban integrated the full sources with Vide and changed (I think 10 lines of code in “WaveformSimilarityBasedOverlapAdd.java“). Also the output seems to be better (less crackling noise) if one switches the use of the “rateTransposer” and “wsola“.
- (example) Code generation was also introduced for the eEprom DS 2430A. Malban also dumped (MVBD – Yeah!) the cartridge version of Protector/YASI and yep, emulation of the DS2430A does work with it too.
- Internally the “connection” of devices to a joystick port drastically changed. Befor devices were more or less hardcoded in vecxi and switched on/off with a flag. Now there is a new “connection” class called “VectrexJoyport.java“. On the one end a vectrex (vecxi) is connected, on the other hand a “device” is connected. Basically the device only knows methods like “setButton1-4()” and “setVertical()“, “setHorizontal()” (and appropriate readers). Everything else is handled in the connection class (like telling the PSG the changed values, triggering CA1 interrupts (or FIRQ for that matter)).
A device can be “plugged” in or out using the the deceptivly clever named method “plugIn(JoyportDevice d)“.
While this now seems to be the logical step Malban should have taken right from the beginning, this is the way if you reuse code and just go straight forward. Not that the original code of vecxi was “bad” – but it was never ment for this kind of flexibility. - Current devices implemented:
KeyboardInputDevice (this handles the “normal” joystick input as befor, as yet not further configurable, the keys ASDF and cursors)
LightpenDevice (I have not tried it in port 0 with the analyser bin, but it might just work out of the box there too)
VecVox
VecVoice (both of them, since they are so similar, are emulated by a VecSpeechDevice) - Devices on the todo-list:
VecLink Version 1
VecLink Version 2
Joystick/Joypad Input devices (actually using a joystick/joypad with Vide)
Imager 3d
Malban also would love a developers version of VecVox, if he ever gets such a thing it will also be “connectable” to port 1!No dates set – but I hope especially the first two “devices” will be more or less “plug and play”.
BugFix:
- the code for via stalling had a bug, the new code behaves more like a real vectrex, although not all possible circumstances have been tested.
(BTW: Malban hates the CLR instruction which (as mentioned before) does first read a value and than writes zero, doing that to a SHIFT reg, which reacts on both read and write is weird… – especially if via is stalling on some specific cycle counts) - in the code for cartridge handling a possible NullPointer was fixed
See ‘ye