Activity for Durandal
-
Durandal modified ticket #2117
ACIA RS232 issue
-
xplus4 broken samples
-
Yes, confirmed fixed
-
Tested with YapeSDL 0.80.1 (July 2024), and samples work fine there.
-
xplus4 broken samples
-
Ah, I've had that happen to me in CCGMS, but is so rare that's no something you think of checking.
-
My tcpser options: -p 6502 -v 25232 -S 57600 -l 4 -i"s5=20" Vice is set to ACIA enabled - $de00 - NMI - Turbo232 - Serial 3 Serial3: 127.0.0.1:25232 - IP232 enabled
-
My tcpser options: -p 6502 -v 25232 -S 57600 -l 4 -i"s5=20" Vice is set to ACIA enabled - $de00 - NMI - Turbo232 - Serial 3 Serial3: 127.0.0.125232 - IP232 enabled
-
With r45431 is working for me, with retroterm, ccgms 2021 and Novaterm 9,6. Using tcpser 1.1.6beta. Under Ubuntu. Does this happens every time? Do you run tcpser before x64? There's a similar problem I sometimes have but with the userport RS232 emulation. It has to do with the DSR line pulsing during reset. That sets tcpser on a intermediate state, were it sees the DSR coming up, but doesnt accepts data coming from x64. The only way out of that state is closing both tcpser and x64 and start agai...
-
Make possible to enable the CP/M cartridge again
-
Display correct column count for VICII and TED
-
Doesn't seem to make any difference
-
1551 drive won't read disk images if (re)enabled at runtime
-
Added row counter and hardware cursor position to TED register info
-
Style changes
-
missing newline
-
Add detailed TED register info for the IO monitor command
-
Fix VIC-II 38 column mode display in the monitor
-
Open address space not emulated in xplus4
-
Added Spanish positional layout for xplus4
-
I'm testing r43721, it seems to be working fine, I tried connecting both Putty and another instance of x64sc using /temp/viceser as the serial device and got bidirectional comms no problem. This method using a pseudo-TTY is less convoluted and error prone than the socat method currently listed in the wiki. If everything works maybe we must add this to the wiki.
-
I'm testing r43721, it seems to be working fine, I tried connecting both Putty and another instance of x64sc using /temp/viceser as the serial device and got bidirectional comms no problem. This method using a pseudo-TTY is less convoluted and error prone than the socat method currently listed in the wiki. I everything works maybe we must add this to the wiki.
-
Custom Kernal ROM image not loaded if the file checksum matches known Kernal image
-
Custom Kernal ROM image not loaded if the file checksum matches known Kernal image
-
VSID extra SIDs not show in monitor IO command
-
Reorder monitor calls so SID appears in address order
-
Only transmit writes to the shift register if the UP9600 mode is enabled
-
What you describe is normal behaviour, at least for CCGMS+TCPSer. The "connect" comes from TCPSer because it got connected to the remote address, regardless if the other terminal issued ATA or not. Conversely, you can type ATH on the remote terminal while is ringing and you'll get "no carrier" on your side. By default TCPSer echoes the characters it receives, so you can see what you type while in full duplex mode. CCGMS does not, so in full duplex you have to type blind if you connect to another...
-
Removed ACIA control line command line option and UI elements. Control line behaviour now depends on machine type, ACIA DCD line mirrors DSR for C64 and C128 based emulators.
-
Removed trailing spaces
-
Add option to change the way DCD & DSR lines are connected to the ACIA, fixes carrier detection and phonebook dialing on several C64/128 terminal software.
-
File transfers fail via userport on 3.5 and earlier versions such as 3.1
-
Missed your reply. Good to know that is working ok for you too now.
-
Update "to do" comments
-
Please test without the -I option in your tcpser setup. I added that switch to my configuration and uploads failed like you described.
-
ACIA: When enabling the transmitter (with IRQ enabled) dont trigger an IRQ instantaneously
-
This is correct, but still I did test uploading to CottomWood (which seems to run on real hardware) and had no problem uploading from Novaterm using Xmodem-CRC, on a 84 block file I only had 1 retry.
-
CPU JAM message in status bar doesn't automatically clear after reset
-
Yeah I was a couple of days behind, current revision doesnt have this problem.
-
CPU JAM message in status bar doesn't automatically clear after reset
-
Thanks for testing, can you tell me specifics on how to reproduce the upload test? I've tested file transfers with two local instances of vice (both using with ACIA): CCGMS -> CCGMS (multipunter) works ok Novaterm -> CCGMS (multipunter) ok DesTerm128 -> CCGMS (Xmodem) ok External BBS (13th Floor) punter download: CCGMS multiple errors, 1 ok block every 20 or more retries. Novaterm works ok.
-
Please build and try with r41228, it should be fixed now.
-
Please build and try with r41280, it should be fixed now. edit: corrected revision number
-
Sorry I should have specified the revision, the new fixes were committed on r41280. Please test again.
-
While I couldn't reproduce your problem, I just fixed some issues on the ACIA core, including reverting one of the changes I had done previously, please check again with a recent version (>= r41280)
-
Please test again with a recent build and report back.
-
RS232 on xplus4
-
Please try again with a recent build, it should be fixed now.
-
Remove previously added condition for transmitter to run only when receiver is enabled.
-
Please build and try with r41228, it should be fixed now.
-
After Raise&Low of DTR, DCD register still see carrier. Turbo232
-
IP232: Dont set DCD if DTR is disabled
-
user port RS232 timings not reinitialized after changing machine mode
-
Unable to connect to tcpser with 9600 baud
-
Yes this is a known issue, UP9600 works only for reception. Data transmission doesn't work yet.
-
Monitor: ACIA state information dump
-
Added missing parallel cable to userport devices id list.
-
Set DSR by default in R232Net, fix ACIA register reset values.
-
Move SuperPET ACIA settings to the RS232 settings section
-
Did you remember to not use the invert DCD option when running TCPSER on windows with the new VICE build?
-
I tested on Win7 and couldnt replicate the problem. At least with CCGMS 2021 + TCPSER
-
RS232 userport emulation DTR rework, code cleanup
-
Yes, this is fixed now
-
Working fine here, both direct connection and through TCPSER
-
Sorry, yes!
-
The problem was that the DCD line level was inverted for the ACIA emulation, but that's something that was not touched by R40836. The network layer uses positive logic while the ACIA uses negative logic for DCD. The network layer also never asserts DCD for direct (non-IP232) connections. This meant DCD was only active for direct connections or, if using TCPSER, before dialling a number or answering a call. On the software side, the routine writing characters to the ACIA Tx register checks for both...
-
I tested an instance of VICE using userport with another using ACIA, the problem is in the transmission line from the ACIA, reception is correct. It seems to be skipping every other outgoing character when writing 'full speed' to the transmit register. Now to find out why this only happens when using interrupts and TCPSER at the same time...
-
Reverted aciacore.c to the previous version (R40434) and it didnt make any difference for me, still cant get to transfer a single block with punter while using TCPSER
-
Reverted aciacore.c to the previous version (R408034) and it didnt make any difference for me, still cant get to transfer a single block with punter while using TCPSER
-
I havent managed to transfer any file using TCPSER, tried with both FozzTexx's version and that vicekludge one. FozzTexx's logs a lot of NVT command parsing messages and eat CPU time when connected to other local instance. The vicekludge version doesn't do that, but in both versions the results are the same: With IP232 ON (as it should be), multipunter outrights cancels on the receiving end when using CCGMS. With Striketerm the receiver shows a mangled filename and 'hangs' there. With IP232 OFF:...
-
I did a test using 2 instances of CCGMS 2021 (with Turbo232 driver at 19200bps selected) using socat on linux. Transferred 3 files using multipunter, 177 blocks total all went through perfectly 0 errors, 0 retries. Just in case, I transferred a single file using punter right after that, it also completed without errors. Can you guide me on how to setup 2 TCPSER instances to talk to each other and VICE? (Edit, nevermind, I figured it out)
-
I did a test using 2 instances of CCGMS 2021 (with Turbo232 driver at 19200bps selected) using socat on linux. Transferred 3 files using multipunter, 177 blocks total all went through perfectly 0 errors, 0 retries. Just in case, I transferred a single file using punter right after that, it also completed without errors. Can you guide me on how to setup 2 TCPSER instances to talk to each other and VICE?
-
Thinking further about this, I figured this patch I wrote is just fixing the symptoms and not the real problem. It's wrong. In VICE the userport RS232 emulation doesnt stablish a connection thru the RS232 driver until the DTR pin goes from high to low. This normally happens in the kernal when the pin goes from input (its pulled up to high) to output (goes to low because the default hard reset value in the PRB register is 0). The kernal then writes 6 to PRB setting DTR to high again. Easyflash sets...
-
Dolphin DOS read/write errors. Not recognizing inserted disk images
-
Hope I got it all right this time. Removed the RsUserModem resource, replaced with RsUserUP9600 indicating the presence of an UP9600 interface. The GTK GUI widgets have been reworked, now the interface type combo box works as a preset list and modifies the control lines resources and RsUserUP9600 resource if that mode is selected from the list. The inverse is also true, if UP9600 mode is not selected, changing the checkboxes for the control lines will update the combo box accordingly. vice.texi is...
-
Hope I got it all right this time. Removed the RsUserModem resource, replaced with RsUserUP9600 indicating the presence of an UP9600 interface. The GTK GUI widgets have been reworked, now the interface type combo box works as a preset list and modifies the control lines resources and RsUserUP9600 resource if that mode is selected from the list. The inverse is also true, if UP9600 mode is not selected, changing the checkboxes for the control lines will update the combo box accordingly. vice.texi is...
-
You're right, it didn't occur to me that making RsUserModem a resource could cause conflicts with the control lines resources. I'll implement normal/UP9600 modes like you suggest.
-
You're right, it didn't occur to me that making RsUserModem could cause conflicts with the control lines resources. I'll implement normal/UP9600 modes like you suggest.
-
I missed those blank lines in aciacore, will remove them. the USERPORT_MD_ constants have confusing names and are not documented in the header. they should be changed to _INVERTED and _NONINVERTED or something like that Yeah, those are better names. the patch is missing the respective changes to doc/vice.texi - ie the documentation of the new features. I forgot completely about the documentation, I'll check it and update it.
-
This time I used a plugin in vscode to generate the patch file instead of using the command line, that plugin must be broken or I didnt used it right. The style issues, at least the one with the switch statement is due to vscode too, it autocompleted the code I just left it as it was :)
-
Updated and bug fixed patch: Adapted to the new userport system: Added a userport modem/interface type widget which can preset the control lines behaviour and baud rate. Fixed a bug when non-inverted RTS was selected. Now the Comet64 38.4Kbaud driver (and cometerm) works correctly Fixed a bug causing the userport RS232 state machine to get stuck in the RTS disabled state. The UP9600 driver install routine now correctly detects the interface when the UP9600 preset is selected. UP9600 reception works...
-
Updated and bug fixed patch: Adapted to the new userport system: Added a userport modem/interface type widget which can preset the control lines behaviour and baud rate. Fixed a bug when non-inverted RTS was selected. Now the Comet64 38.4Kbaud driver (and cometerm) works correctly Fixed a bug causing the userport RS232 state machine to get stuck in the RTS disabled state. The UP9600 driver install routine now correctly detects the interface when the UP9600 preset is selected. UP9600 reception works...
-
Updated and bug fixed patch: Adapted to the new userport system: Added a userport modem/interface type widget which can preset the control lines behaviour and baud rate. Fixed a bug when non-inverted RTS was selected Fixed a bug causing the userport RS232 state machine to get stuck in the RTS disabled state. The UP9600 driver install routine now correctly detects the interface when the UP9600 preset is selected. UP9600 reception works correctly, transmission is garbled. For complete UP9600 emulation...
-
Spanish keyboard GTK positional keymap
-
Fix missing parallel drive cable userport device id
-
After the fixing of bug #1531, I could do proper testing on x128 and Desterm and discovered I needed to invert the RTS and CTS lines at the same time. Now the "Invert CTS" setting in the GUI is labelled invert RTS/CTS and the resource name was changed to "RsUserFlowInv". Attached below is a patch that adds this fix, against rev 40580 This should allow for most comm software/modem/userport RS232 interface combinations.
-
That original htst.prg was made specifically to be loaded and run after desboot.prg I updated the code to write to the ghostbyte at $3FFF !to "htst.prg" *=$1c01 SYSLine: !byte $0B, $1C, $CE, $07, $9E, $37, $31, $38 !byte $31, $00, $00, $00 MainStart: ldx #$FF lda #$0E sta $FF00 ; MMU CR lda #$00 sta $D020 ; Border sta $D021 ; Background lda #$08 sta $D011 lda #$01 sta $D030 ; Processor Clock Register lda #$03 sta $3FFF ; Write ghost byte for test HartDetect: lda #$03 sta $D71B lda $D71B cmp #$03...
-
In the real hardware there's 4 color bands on screen, but there's 1 or 2 scanlines in between each that change color multiple times. I haven't traced all of desboot.prg, but using a watchpoint on vice's monitor it seems the detection code is synced with vic's raster, accessing $d71b at regular intervals on raster lines 177 - 208
-
Todays tests showed that the $03 appearing on the open space is not a result of running desboot.prg but it appears right after loading it. A repeating value appears on the open space after loading any program large enough (it doesnt happen with the small <1 block test programs) and the value is different for each it just happen that it matches the value desterm checks for. This is true for both x128 and the real hardware. Still, I ran desboot on the RH and it never detected the Hart cartridge by...
-
Todays tests showed that the $03 appearing on the open space is not a result of running desboot.prg but it appears right after loading it. A repeating value appears on the open space after loading any program large enough (it doesnt happen with the small <1 block test programs) and the value is different for each it just happen that it matches the value desterm checks for. This is true for both x128 and the real hardware. Still, I ran desboot on the RH and it never detected the Hart cartridge by...
-
Did some digging and testing, on desboot.prg the Hart cartridge is checked for on 3 addresses: $D71B, $DE1B and $DF1B I also noticed that sometimes DesTerm128 would detect the cartridge at "DE00" instead of "D700" The routine checks for a 8250 UART by writing $03 to the Line Control Register and expecting the same value when reading back the register. ;This routine is called 3 times ;with $FB/$FC containing $D718, $DE18 and $DF18 HartDetect: ldy #$03 lda #$03 sta ($FB),y ; Not used lda ($FB),y ;...
-
I'll try disassembling desboot.prg, and will report later.
-
Yeah, the ROM monitor shows the same kind of random values than the real hardware, but there seems to be a higher prevalence of 00 values.
-
Issuing M 4D700 4D7FF on the 128 ROM monitor. It shows random values, different every time the command is issued. Values are mostly 00, FF, 3x (with bit 3 always on), 60, 66, 6E and very rarely C9, 18 or other values. Tested both with and without Ultimate II cartridge inserted. No changes observed
-
Misc. RS232 emulation improvements
-
Hart cartridge detected at $D700 by DesTerm128 at startup
-
Missing baudrates in rs232-unix-dev.c
-
My fault, had old files (crt.c and crt.h) mixed with the new ones. Have tested and can confirm that RS232 timings are now set correctly when changing machine modes from the GUI.
-
My fault, had old files (crt.c and crt.h) mixed with the new ones. Have tested and can confirm that RS232 timings are new set correctly when changing machine modes from the GUI.
-
Can't get r39843 to compile under linux, dunno if it is a problem on my side or if I should open a new ticket. Getting this error: c64cart.c:633:12: error: static declaration of ‘crt_attach’ follows non-static declaration 633 | static int crt_attach(const char filename, uint8_t rawcart)
1 >
