Control:
1. Load the attached .ini settings.
2. Load and run testcase.prg. You should see a directory come through at 300 baud.
To reproduce bug:
1. Load the attached .ini settings.
2. Attach the included testcase.crt image
3. Use F2 to go straight to basic w/o loading anything.
3. Load and run testcase.prg
With the .crt attached, nothing comes back. Note that on real hardware, we use easyflash all the time with RS-232 and there is no conflict.
I suspect that attaching ANY cart would trigger the same problem, but since all the .crt images I have are games, and there's no reason why EF should prevent RS-232 from working, I didn't bother hunting down a regular non-game cart.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
unfortunately the service that the url in the .ini is connecting to is down right now. I've notified the sysop. Try again in a bit, or substitute any other telnet ip:port to see SOMETHING come back.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
All you need is an internet connection. The service should always be up and running. Let me know if you have any trouble getting results with the control.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ok, managed to reproduce (its a bit tricky with wine on linux hehe). i noticed that simply detaching the cartridge makes rs232 emulation work again, so there probably is indeed some kind of correlation.
assigning to blacky, since this is a windows specific problem (or atleast, rs232 can not be used that way in linux)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
that fix is almost certainly wrong, there is no reason you should ignore ddr when writing to port b, the proper way to solve it is: first check the behaviour on a real c64. and if that actually works, the problem is more likely in the logic that handles the userport rs232. And then we should come up with a simple test program that reproduces the problem, ie works on c64 and not in VICE. Dont assume running random programs, or even the testbench, can actually prove you didnt break something - it can only prove you DID break something, when a program that worked before stops working, not the other way around.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
that fix is almost certainly wrong, there is no reason you should ignore ddr when writing to port b
oops disregard, i misread the patch - it actually adds that!. The rest still stands though - we need a program to reproduce the problem before we can apply the patch - the CIA core is just too important for experiments.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To add on this, i think the cia_context->c_cia values should always contain what was actually written to them, ie what is missing is some masking with DDR elsewhere in the code
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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 PRB to $FF by default, then when the DTR pin changes from input to output in never goes down and thus the userport RS232 never initiates a connection.
I have no idea about the modems used back in the day, but nowadays wifi modems and rs232 userport interfaces ignore DTR altogether (is not connected).
A solution might be to simply initiate the connection with the RS232 driver the moment the userport RS232 emulation is enabled.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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 PRB to $FF by default, then when the DTR pin changes from input to output in never goes down and thus the userport RS232 never initiates a connection.
That sounds like it would not work on a real C64 either - the emulation should be able to deal with this correctly (changing the port status by changing DDR) - which is indeed why your patch is wrong :)
It'd really help if someone could confirm this on the real thing. My rs232 interface is broken unfortunately, so i cant help here :/
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
just for the records: kernal initializes the CIA2 ports like this - interestingly the portb output value is NOT initialized - so the kernel itself relies on the power up value in the CIA!
just for the records: kernal initializes the CIA2 ports like this - interestingly, the portb output value is NOT initialized - so the kernel itself relies on the power-up value in the CIA!
KERNAL doesn't set the output value because it's irrelevant -- all pins are set to input.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
could you provide a testcase for this?
.crt, .ini, and test program
Test case attached.
Control:
1. Load the attached .ini settings.
2. Load and run testcase.prg. You should see a directory come through at 300 baud.
To reproduce bug:
1. Load the attached .ini settings.
2. Attach the included testcase.crt image
3. Use F2 to go straight to basic w/o loading anything.
3. Load and run testcase.prg
With the .crt attached, nothing comes back. Note that on real hardware, we use easyflash all the time with RS-232 and there is no conflict.
I suspect that attaching ANY cart would trigger the same problem, but since all the .crt images I have are games, and there's no reason why EF should prevent RS-232 from working, I didn't bother hunting down a regular non-game cart.
err? there surely has to be something connected on the other end of the rs232 ?
unfortunately the service that the url in the .ini is connecting to is down right now. I've notified the sysop. Try again in a bit, or substitute any other telnet ip:port to see SOMETHING come back.
All you need is an internet connection. The service should always be up and running. Let me know if you have any trouble getting results with the control.
ok, managed to reproduce (its a bit tricky with wine on linux hehe). i noticed that simply detaching the cartridge makes rs232 emulation work again, so there probably is indeed some kind of correlation.
assigning to blacky, since this is a windows specific problem (or atleast, rs232 can not be used that way in linux)
can someone test if this works with GTK3 please?
please?
relaying from IRC:
again relaying from IRC :)
that fix is almost certainly wrong, there is no reason you should ignore ddr when writing to port b, the proper way to solve it is: first check the behaviour on a real c64. and if that actually works, the problem is more likely in the logic that handles the userport rs232. And then we should come up with a simple test program that reproduces the problem, ie works on c64 and not in VICE. Dont assume running random programs, or even the testbench, can actually prove you didnt break something - it can only prove you DID break something, when a program that worked before stops working, not the other way around.
oops disregard, i misread the patch - it actually adds that!. The rest still stands though - we need a program to reproduce the problem before we can apply the patch - the CIA core is just too important for experiments.
To add on this, i think the cia_context->c_cia values should always contain what was actually written to them, ie what is missing is some masking with DDR elsewhere in the code
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 PRB to $FF by default, then when the DTR pin changes from input to output in never goes down and thus the userport RS232 never initiates a connection.
I have no idea about the modems used back in the day, but nowadays wifi modems and rs232 userport interfaces ignore DTR altogether (is not connected).
A solution might be to simply initiate the connection with the RS232 driver the moment the userport RS232 emulation is enabled.
That sounds like it would not work on a real C64 either - the emulation should be able to deal with this correctly (changing the port status by changing DDR) - which is indeed why your patch is wrong :)
It'd really help if someone could confirm this on the real thing. My rs232 interface is broken unfortunately, so i cant help here :/
just for the records: kernal initializes the CIA2 ports like this - interestingly the portb output value is NOT initialized - so the kernel itself relies on the power up value in the CIA!
KERNAL doesn't set the output value because it's irrelevant -- all pins are set to input.
yes and no - it only works if you rely on those registers being untouched by other programs.
closing this - i am convinced enough that this is not an emulation problem, but simply a software issue