BenjaminLumen wrote:Hmmmmm,
Have you tried the commodore schematic? 6526 CIA... Hmmm, how to get that puppy moving???
Hi, yes I did it actually. We got two puppies, and the focus is now on the second one.
BenjaminLumen wrote:
The 2Mhz version of the 6526 would accept max bit rates of 500Kb/Sec....
Well yes, but since the C64s and lot of C128s were equipped with the 1MHz version, so...
It might not relevant in our case.
BenjaminLumen wrote:
Hmmm, Test it against a C128....
That was came into my mind as well, then I've checked the C128 schematics...
Even the versions equipped with the 2MHz capable 6526A are driving the CIAs with
same 1MHz clock speed, therefore no significant differences are expected,
nor in C128 fast mode.
BenjaminLumen wrote:
The 6526 is also used for Parallel coms.... 2400bps.......
Indeed. The goal would be break the serial 2400bps barrier with the same hardware.
BenjaminLumen wrote:
As configured in the Commodore 64 and Commodore 128, the CIA's timing was controlled by the phase two system clock, nominally one MHz. This meant that the timers decremented at approximately one microsecond intervals, the exact time period being determined by whether the system used the NTSC or PAL video standard. In the C-128, clock stretching was employed so the CIA's timing was unaffected by whether the system was running in SLOW or FAST mode.
Agreed, Wiki says exactly the same
The C-128 related part confirms that, there would be no difference
in speed compared to the C64.
BenjaminLumen wrote:
Hmmm, it could be multiplexing (correct term?) and that is why you can't get the ... It is also used for the User Port and 2 Controller Ports, and in a Von Neuman setup it may be looking for all of it, so its 19,200 is divided by 4 and your back to 2400bps.. which may explain it... Its doing a lot in the C64... If the Computer had a dedicated 6526 for every port then you could probably get the 19.2Kbps you were looking for but still, there may be a way to do it..
Oh there it is , its the Keyboard, and 2 controller ports... Its always looking for keyboard input, you may look for a way to halve or quarter the amount of time it looks for keyboard input and then type and execute the program...
If the 6526 only spends 1/4 of its usual time looking at the controller ports or keyboard ports you may get to 4800, 9600bps on the serial...
Okay sooo look at the keyboard timming routines and the controller port routines...
I think we need to separate things here. The second 6526 doesn't have to deal with the keyboard or the controller ports,
it's (almost) fully available to the user, this chip is in the focus. The first 6526 is responsible for the things you mentioned, but
since the controller ports lines and some of the keyboard matrix lines are connected together, the scan of keyboard and control
ports is done simultaneously: e.g. when you press key "2" on the keyboard that changes the state of the control port#1 as well
(@ decimal address 56321, even without joystick connected) and vice versa: changing the control port status with the joystick
affects the keyboard matrix state. As far as I can tell no extra cycles/time sharing needed for the keyboard and control port
handling, so I guess this might not the root cause.
Meanwhile I've started to scrutinize the ROM routine starting at $EED7. In this routine the state of RS-232 control register (@ decimal 659)
mentioned in the first post is being read and processed. Since the last post I got a bit overloaded at work, so I didn't get too far with it.
Anyway, thank you for sharing your thoughts, while writing these lines I got some new ideas regarding how to get around this
limitation with a machine language program which uses some of the original ROM routines.
All the Best!