Of course, that won't work full speed with the standard
IRQ-based RX. But that will allow users to setup the port
at this speed without duplicating the setup part of the
code. Up to them to add hooks to disable IRQs and read
directly in a tight asm loop.
Of course, that won't work full speed with the
standard IRQ-based RX. But that will allow users
to setup the port at this speed without duplicating
the setup part of the code. Up to them to add hooks
to disable IRQs and read directly in a tight asm
loop.
The Pascal Firmware Protocol Bytes ID are not enough to differentiate an SSC card from a IIgs serial firmware:
http://www.1000bit.it/support/manuali/apple/technotes/misc/tn.misc.08.html
Loading a2(e).ssc.ser on a IIgs succeeds, then goes to limbo when one tries to use the serial port.
Check first byte on the slot's firmware in addition to the four existing ones, as it's supposed to be $2C (BIT instruction) on an SSC card, and $EF (65C816 SEP instruction) on the IIgs' serial firmware (ROM revisions 0, 1, 3).
There is no need to TryToSend before getting the character. We
send bytes during SER_PUT, and if interrupted during sending, we
still try to do it at the beginning of the next SER_PUT.
Apple2 and Atmos have Index in X, but can still use it for the
best-case path as long as we reload it in the worst-case part
(when we assert flow control).
Also, standardize the free space to trigger flow control to 32
characters left (compare with RecvFreeCnt before decrement)
The Receive Data Register and the Transmit Data Register share share a single address. Accessing that address with STA abs,X in order to fill the Transmit Data Register causes a 6502 false read which causes the Receive Data Register to be emptied.
The simplest way to work around that issue - which I chose here - is to move the base address for all ACIA accesses from page $C0 to page $BF. However, that adds an additional cycle to all read accesses. An alternative approach would be to only modify the single line `sta ACIA_DATA,x`.
Up to now static drivers were created via co65 from dynamic drivers. However there was an issue with that approach:
The dynamic drivers are "o65 simple files" which obligates that they start with the 'code' segment. However dynamic drivers need to start with the module header - which is written to. For dynamic drivers this isn't more than a conceptual issue because they are always contain a 'data' segment and may therefore only be loaded into writable memory.
However when dynamic drivers are converted to static drivers using co65 then that issue becomes a real problem as then the 'code' segment may end up in non-writable memory - and thus writing to the module header fails.
Instead of changing the way dynamic drivers work I opted to rather make static driver creation totally independent from dynamic drivers. This allows to place the module header in the 'data' segment (see 'module.mac').
This change was suppsed to fix the issue that the former JUMPTABLE is merked as 'ro' while it is actually written to in several scenarios. When drivers are converted using co65 and then compiled into ROMs the JUMPTABLE isn't copied to RAM and therefore the write operations in question fail.
However unfortunately I didn't succeed in changing that :-( Just setting the former JUMPTABLE to 'rw' broke the drivers. So I placed the DATA segment directly after the former JUMPTABLE segment. This made the drivers converted with co65 work again - obviously after changing libsrc/Makefile:235 from '--code-label' to '--data-label'. But the actual dynamic drivers still didn't work as the former JUMPTABLE wasn't placed as the beginning of the loaded file anymore. That effect could be changed by exchanging src/ld65/o65.c:1391 with src/ld65/o65.c:1394 but doing so broke the drivers again :-((
- No complex shell logic.
- "Source file shadowing" for all targets via vpath.
- Dependency handling.
- True incremental build.
- Don't write into source directories.
- Easy cleanup by just removing 'wrk'.
