Activity for Vic Chwe
-
Vic Chwe posted a comment on ticket #153
I have totally missed the fact that IF1 ULA detects the falling edge of the byte leader pulse, thus providing hardware synchronisation for every byte. With that in mind, "playback" works and broadcast transmissions are working, too. Code is nice and clean and I like it. However, there is a significant (~5 msec) delay before the receiving machine sees inbound data and it breaks everything because at the time receiver sends ACK back to the sender the sender has already started re-transmission. Latest...
-
Most of the programmes (I've seen so far) utilising CMD18 and CMD25 seem to expect Z-Controller SD card interface, and those appear to be using quite a lot of SPI mode commands. Next revision of the patch, adds basic support for CMD16 and CMD59.
-
SD Card: multiple block read/write support
-
Unfortunately, at the moment I do not fully understand all the subtleties of IF1 protocol and I could not get a (reliably) working prototype. I am publishing my changes in case if someone is able to pick it up. Updated 2024-09-28: Cleaned up code, slightly easier to read (and smaller)
-
All configuration options can be changed via command line arguments. Those override anything found in config file. Unfortunately, it means that changing configuration file location using a command line argument is not that simple. A while ago I thought I needed that option anyway, so I created a naive implementation. I have not used it for a while and it MAY NOT work with all build targets! That is why I am not creating a separate patch ticket and simply attaching my changes here.
-
Unfortunately, at the moment I do not fully understand all the subtleties of IF1 protocol and I could not get a (reliably) working prototype. I am publishing my changes in case if someone is able to pick it up.
-
I’ve managed to create a simple “wire” simulation code. With that code the broadcast transmissions are now being sent out successfully. There are some peculiarities of the IF1 schematics and ROM code, which I do not fully understand (hopefully, yet). If someone has a clear explanation, please share. Right now I rely on Gergely’s comments for if1.c, IF1 ROM disassembly, experimental data, and my very limited understanding of the IF1 schematics. Anyway, here is what I observe “inside” FUSE: SCOUT frame:...
-
I’ve managed to create a simple “wire” simulation code. With that code the broadcast transmissions are now being sent out successfully. There are some peculiarities of the IF1 schematics and ROM code, which I do not fully understand (hopefully, yet). If someone has a clear explanation, please share. Right now I rely on Gergely’s comments for if1.c, IF1 ROM disassembly, experimental data, and my very limited understanding of the IF1 schematics. Anyway, here is what I observe “inside” FUSE: SCOUT frame:...
-
Quick summary of the Spectrum Computing discussion: - existing code was not finished (and it tries to analyse the sequence of IN/OUT calls, which seems to be a tricky task) - suggestion to intercept IF1 ROM routines (like it’s done for tape loader) was considered, but rejected I would suggest implementing another approach: build a proper parser for the ZX Net protocol which will serve as an adapter between the IF1 network “socket” (port 0xF7, technically) and the virtual “wire”. Such parser will...
-
We’ve been discussing this feature on the SpectrumComputing forums for a while, and here are some things mentioned so far about existing (POC?) code: There may be a bug in if1.c:port_net_out, which prevents network from “sending” anything unless RS232 is “connected”: diff --git a/peripherals/if1.c b/peripherals/if1.c index b4ff329..2ed8083 100644 --- a/peripherals/if1.c +++ b/peripherals/if1.c @@ -922,8 +922,8 @@ port_ctr_out( libspectrum_byte val ) static void port_net_out( libspectrum_byte val...
-
We’ve been discussing this feature on the SpectrumComputing forums for a while, and here are some things mentioned so far about existing (POC?) code: There may be a bug in if1.c:port_net_out, which prevents network from “sending” anything unless RS232 is “connected”: diff --git a/peripherals/if1.c b/peripherals/if1.c index b4ff329..2ed8083 100644 --- a/peripherals/if1.c +++ b/peripherals/if1.c @@ -922,8 +922,8 @@ port_ctr_out( libspectrum_byte val ) static void port_net_out( libspectrum_byte val...
-
(Hopefully) the final version of the patch, includes UI elements and man page. Things that can be improved: - printer support can be streamlined, I did not touch existing printer code on purpose - Win32 port
-
(Hopefully) the final version of the patch, includes UI elements and man page. Things that can be improved: - printer support can be streamlined, I did not touch existing printer code on purpose - Win32 port
-
The patch is not compatible with the modern high speed software, like sercp. I presume the tstates-based "timer emulation" is not precise enough. If I tweak the code to send each bit every 90 tstates for 38400 and every 30 tstates for 115200, the sercp 0.8 works. However, lookin at the sercp code, it actually spends 91 and 31 tstates polling each bit at 38400 and 115200 respectively. However, it seems to be compatible with anything using ROM or CP/M routines for RS232/MIDI comms.
-
Almost complete functional changes. Remaining tasks: UI replace existing serial printer emulation multiplatform support (at least making sure it compiles anywhere) cleanup code :) The following settings available (command line only): --ay-io-device TYPE - where TYPE is None, RS232 or MIDI for MIDI the following options available: --ay-io-midi-tx FILE - attach MIDI receiver (e.g. amidicat http://krellan.com/amidicat/ ) for RS232 the following options available: --ay-io-rs232-baud - choose the speed...
-
Almost complete functional changes. Remaining tasks: UI replace existing serial printer emulation multiplatform support (at least making sure it compiles anywhere) cleanup code :) The following settings available (command line only): --ay-io-device TYPE - where TYPE is None, RS232 or MIDI for MIDI the following options available: --ay-io-midi-tx FILE - attach MIDI receiver (e.g. amidicat http://krellan.com/amidicat/ ) for RS232 the following options available: --ay-io-rs232-baud - choose the speed...
-
Almost complete functional changes. Remaining tasks: UI replace existing serial printer emulation multiplatform support (at least making sure it compiles anywhere) cleanup code :) The following settings available (command line only): --ay-io-device TYPE - where TYPE is None, RS232 or MIDI for MIDI the following options available: --ay-io-midi-tx FILE - attach MIDI receiver (e.g. amidicat http://krellan.com/amidicat/ ) for RS232 the following options available: --ay-io-rs232-baud - choose the speed...
-
Almost complete functional changes. Remaining tasks: UI replace existing serial printer emulation multiplatform support (at least making sure it compiles anywhere) cleanup code :) The following settings available (command line only): --ay_io_device TYPE - where TYPE is None, RS232 or MIDI for MIDI the following options available: --ay_io_midi_tx FILE - attach MIDI receiver (e.g. amidicat http://krellan.com/amidicat/ ) for RS232 the following options available: --ay_io_rs232_baud - choose the speed...
-
Thanks a lot for the inspiration! I have created an enhanced version which should be able to handle any arbitrary baud rate: https://sourceforge.net/p/fuse-emulator/patches/442/
-
AY RS232 interface for 128/+2/+3
-
That's great news, thank you very much Sergio! I've just managed to get another recording from a real unit, so here is it attached along with the same think "sp oken" by the latest FUSE. T. Busse's currah_uspeech_tests.tap, test "All allopho nes (5-63)". uSpeech unit -- uspeech-all.wav, FUSE [68cb83] -- fuse-68cb83-all.wav. And, of course, I was able to build the latest code and it seems to be working fine with a few games I usually use for testing (Booty, Moon Patrol, Starbike). Please let me know...
-
Fantastic update, thank you very much! Tested it briefly, all seems to be working. I have a sample recording from the real unit, but I am not going to upload everything right now since those PCM files are quite large. So, here is the"fuse-uspeech-comparision" PCM, just two tracks mixed together, real uSpeech unit goes first, then the same repeated by the FUSE with intonation.diff applied. FUSE's part is easy to spot, it has a loud leading click, this is the button press sound missing from the uSpeech...
-
Alright, that wasn't truly scientific experiment*, but I've managed to find a person who was willing to test a real unit for me. Long story short: Spectrum +2, Grey model, does NOT work with uSpeech unit. Surprisingly, the results are a bit random. 3 out of 5 tries, it yields completely unbootable system which looks like a system with RAM fault, except that the machine itself is back to normal as soon as uSpeech is unplugged. Other times it boots into a state resembling USR 0 mode that esxdos is...
-
Separated original patch diff.upd_scan_bug.patch into the bugfix itself and the debugging code. Hope it helps merging. DISCKIT.COM now works as expected no more "check read" errors, I was able to format and copy disks. Have not tried Fusix yet.
-
Great findings! Happy to confirm, the quality of "speech" is much improved with this patch applied.
-
BTW, tested this patch with a few games, all seems to be fine.
-
In order to clarify it I've tried emailing Kio, but got no response so far. Checking zxsp sources, it looks like uSpeech is enabled for 48k models only: Source/Qt/MachineController.cpp#L1334 1333 if (model_info->rom_size == 16 * 1024) 1334 add_actions.append(action_addCurrahMicroSpeech); // only 48k machines work To verify that I managed to build Kio's zxsp [on Linux]. It does not work [yet], as expected, but the UI elements seem to be functional. And it looks like it only enables uSpeech unit for...
-
In order to clarify it I've tried emailing Kio, but got no response so far. Checking zxsp sources, it looks like uSpeech is enabled for 48k models only. To verify that I managed to build Kio's zxsp [on Linux]. It does not work [yet], as expected, but the UI elements seem to be functional. And it looks like it only enables uSpeech unit for 48k models. When I switch emulated hardware to 128k, "Extensions" menu has no "uSpeech" entry.
-
Unfortunately, I don't have physical unit, but personally I doubt it will be compatible with 128k (one more source claims so). Besides potential ports conflict (in case code actually does IN/OUT 38h), the RST handler code may not match handler in 128k ROMs. A few videos I've seen, they all show original 48k or Plus models. Here is zxsp's implementation, it includes some clarifying comments from kio and T. Busse.
-
Brilliant! Thank you very much! I was going to research it last weekend, but haven't had time.
-
Thanks a lot! This is really great! For anyone who is able to test the proposed changes. This patch affects the following areas: SP0256/µSpeech emulation itself basic snapshot capabilities (enabled/disabled) UI elements: General control under Options -> Peripherals -> Sound ROM selection UI under Options -> Select ROMs -> Peripheral ROMs -- two entries, SP0256 and uSpeech Volume controls under Options -> Sound and, of course, the man page Hence, the basic regression test may look like (assuming you...
-
For converting the al2.bin ROM, there is Sergio's one liner for perl and attached Python code can do the same. Note that sp0256-al2.rom is supposed to have SHA1 sum e60fcb5fa16ff3f3b69d36c7a6e955744d3feafc, the al2.bin ROM's SHA1 is 86fb6d9fef955ac0bc76e0c45c66585946d278a1 but al2.bin should NOT be used without conversion!
-
I am able to build libsprectum (1ec4c7dab04bf9240e405258854bfec858be500f) and fuse (b5830f37fef7a8e0a91ddf5235966dc3a9e1d772) from that branch and it seems to be working as expected. I think there is a discrepancy in the menu.c::MENU_CALLBACK_WITH_ACTION, where the indices for ROM entries have a wrong order making it impossible to update ROM file location for anything below "Opus Discovery". The following patch should fix it: diff --git a/menu.c b/menu.c index 99835be..b42e3ad 100644 --- a/menu.c...
-
I am able to build libsprectum (1ec4c7dab04bf9240e405258854bfec858be500f) and fuse (b5830f37fef7a8e0a91ddf5235966dc3a9e1d772) from that branch and it seem to be working as expected. I think there is a discrepancy in the menu.c::MENU_CALLBACK_WITH_ACTION, where the indices for ROM entries have a wrong order making it impossible to update ROM file location for anything below "Opus Discovery". The following patch should fix it: diff --git a/menu.c b/menu.c index 99835be..b42e3ad 100644 --- a/menu.c...
-
I am able to build libsprectum (1ec4c7dab04bf9240e405258854bfec858be500f) and fuse (b5830f37fef7a8e0a91ddf5235966dc3a9e1d772) from that branch and it seem to be working as expected. I think there is a discrepancy in the menu.c::MENU_CALLBACK_WITH_ACTION, where the indices for ROM entries have a wrong order making it impossible to update ROM file location for anything below "Opus Discovery". The following patch should fix it: diff --git a/menu.c b/menu.c index 99835be..b42e3ad 100644 --- a/menu.c...
-
Apologies, a bit late to the party. I was trying Colour Clash because several sources (e.g. the one linked from wikipedia) claim that it supports uSpeech. Looks like it does not, but it has an unusual loading sequence which overrides system vars in the process. The way I understand it, it loads the main game code block together with screen (starting from 16384), overwriting system variables in the process. That naturally changes RAMTOP, STKEND and any other variables and they are no longer accounting...
-
Apologies, a bit late to the party. I was trying Colour Clash because several sources (e.g. the one linked from wikipedia) claim that it supports uSpeech. Looks like it does not, but it has an unusual loading sequence which overrides system vars in the process. The way I understand it, it loads the main game code block together with screen (starting from 16384), overwriting system variables in the process. That naturally changes RAMTOP, STKEND and any other variables and they are no longer accounting...
-
I've tested as many games as I could, pretty much everything seems to be working with the exception of Colour Clash. I do not understand how exactly uSpeech is supposed to be working there and quick disassembly doesn't show any access to relevant ports/addresses, but something is clearly broken when uSpeech is enabled. Any other game I tried seem to be fine.
-
I've tested as many games as I could, pretty much everything seems to be working with the exception of Colour Clash. I do not understand how exactly uSpeech is supposed to be working the, but something is clearly broken when uSpeech is enabled. Any other game I tried seem to be fine.
-
Here is my attempt to get all bits together. This patch replaces the "sp0256-rom-ui.diff" I posted earlier. Key changes in these patches: Snapshots enabled, per https://www.spectaculator.com/docs/zx-state/uspeech.shtml. The uspeech ROM and SP0256 ROM are NOT persisted, if I understand it correctly, that would be an unofficial addition to the SZX spec. Frankly, I am not sure how to implemented it, too. SP0256 ROM initialisation moved to the uspeech.c and produces meaningful error messages if something...
-
Here is my attempt to get all bits together. This patch replaces the "sp0256-rom-ui.diff" I posted earlier. Key changes in these patches: Snapshots enabled, per https://www.spectaculator.com/docs/zx-state/uspeech.shtml. The uspeech ROM and SP0256 ROM are NOT persisted, if I understand it correctly, that would be an unofficial addition to the SZX spec. Frankly, I am not sure how to implemented it, too. SP0256 ROM initialisation moved to the uspeech.c and produces meaningful error messages if something...
-
Here is my attempt to get all bits together. This patch replaces the "sp0256-rom-ui.diff" I posted earlier. Key changes in these patches: Snapshots enabled, per https://www.spectaculator.com/docs/zx-state/uspeech.shtml. The uspeech ROM and SP0256 ROM are NOT persisted, if I understand it correctly, that would be an unofficial addition to the SZX spec. Frankly, I am not sure how to implemented it, too. SP0256 ROM initialisation moved to the uspeech.c and produces meaningful error messages if something...
-
Here is my attempt to get all bits together. This patch replaces the "sp0256-rom-ui.diff" I posted earlier. Key changes in these patches: Snapshots enabled, per https://www.spectaculator.com/docs/zx-state/uspeech.shtml. The uspeech ROM and SP0256 ROM are NOT persisted, if I understand it correctly, that would be an unofficial addition to the SZX spec. Frankly, I am not sure how to implemented it, too. SP0256 ROM initialisation moved to the uspeech.c and produces meaningful error messages if something...
-
+1 to Paul's request, the patch seems to be working as of June 2023. Could we merge it, please?
-
Thank you! Happy to confirm, it works both ways (with v2.0 installer and with the trunk fuse-emulator-fuse codebase and R1002 installer).
-
Thanks a lot for reviewing it! Attached is an additional patch to be applied on top of your 0001-Initial-support-for-uSpeech-peripheral.patch. It changes the SP0256 ROM loading sequence (to be honest I am not quite sure about it) and adds necessary UI elements to manage sp0256_1.bin location. With the new init sequence, calling sp0256_do_frame() unconditionally didn't make much sense, so I added a simple "if" there. Basically, I was trying to resolve the following: 1. sp0256_1.bin was always loaded...
-
Spectranet is broken as of (at least) 1.6.0
-
Just a crude update for the uspeech-4.diff to make it compatible with the 1.6.0 release. No functional changes whatsoever. It seems to work rather well though, considering its prototype nature. Unfortunately, I do not have enough knowledge of FUSE internals (yet) to turn it into release-ready code. In case if someone is able to pick it up, the way I understand the following enhancements will help: 1. The sp0256_rdrom(...) routine needs to be updated to load sp0256_1.bin from a proper location (roms?)....
-
Just a crude update for the uspeech-4.diff to make it compatible with the 1.6.0 release. No functional changes whatsoever. It seems to work rather well though, considering its prototype nature. Unfortunately, I do not have enough knowledge of FUSE internals (yet) to turn it into release-ready code. In case if someone if able to pick it up, the way I understand the following enhancements will help: 1. The sp0256_rdrom(...) routine needs to be updated to load sp0256_1.bin from a proper location (roms?)....
1
