LX.NET

I'll look into this if I have some time left. Interested to see how it all works. Thanks for sharing.

Let's see if I understand it better now. The global palette for the colors defines the colors per pen 0 through F. In your SCB penpal you pick a color from that palette, taking into account that 0, E and F might be special depending on your sprite type. So, it is not the index of the penpal that is determining what is special, but what color index from the palette you choose. Correct? And for additional educational purposes: @Nop90: should your example define just one byte in the penpal, instead of 8? I thought that was the case, because BPP_1 only loads a single byte for two colors.

Sprite TYPE_NORMAL should have a transparent pen 0. Make sure you use that pen for drawing. I am not sure how it all works for BPP lower than 4, as the documentation states that the pens E and F are special, 1-D are fairly normal. In BPP_1 through BPP_3 those pens are not available, how would you do a shadow or boundary pen?

Here is a special fixed version for the GameDrive. It doesn't save progress to EEPROM and can be used on all cartridge types. Saving custom levels in the designer is also not enabled. You can design and play custom levels. I will create a special version that allows saving on GameDrive, or perhaps a version that can switch between no EEPROM, EEPROM or GameDrive support. Let's see. Please do know that I am working with Jonathon Holmes on a color version of this game. It might be released on physical cartridge later on. Also, we are working on uploading custom levels over the serial ComLynx cable from a laptop or PC. Stay tuned. circuitdude-beta2-gamedrive.lnx

More changes were made and the pull request has been reviewed and approved. The code is emerged, so on a new build of cc65 and the lynx.lib library you will get the latest implementation for serial support. Thanks to @karri and @42bs for their support!

On real hardware the color is red for correctly placed tiles indeed.

Thanks very much! I appreciate it very much. I made a single change to the code so far. I explained why the other things are as they are now. If you feel these should be changed, please let me know on GitHub. Thanks again.

Thanks @karri. I appreciate that coming from you. All, I have uploaded my code and submitted a pull request for this. Feel free to discuss and comment on the changes. https://github.com/cc65/cc65/pull/2410 Edit: the request has been made to verify the new code. Who can and wants to check it and comment at GitHub? @karri and @42bs, would you want to have a look at the code? Thanks!

I've added some additional code to the ser_open method, so it detects whether the comlynx cable is connected or not. lda IODAT and #NOEXP ; Check if redeye bit flag is unset beq redeye_ok lda #SER_ERR_NO_DEVICE ; ComLynx cable is not inserted ldx #0 rts Would this be useful to add to the new serial support implementation? What do you think? It might also be check only when relevant, e.g. when the handshake is hardware. It would be a bit of a misuse of the SER_HS_HW setting in the serial parameters, but it gives the option to check for it or not. Again, any opinions and advice welcome.

Really nice demos. Amazing what you can do in 256 byte.

I have implemented parity and mark/space checking for receiving bytes in the source code and started testing. Since I am novice at 6502 assembly, I would appreciate any and all of you checking the source code as it is now. I saw that the original implementation of lynx-comlynx.s was taken from @42bs serial.inc implementation. You can find the new code here. Changes made: Removed duplicate code (clearing errors for receive and (re)enabling RX-IRQ) Added mark/space parity checking Fixed achievable baud rates. (Confirmed: 300, 600, 1200, 2400, 4800, 9600, 31250, 62500) Removed baud rates 3600 and 7200, as these were not achievable according to my calculations Discarded prescaler logic and changed selection of clock select and backup value for timer 4 in baud rate setting Added logic to do a proper close on serial port Still looking into low baud rates. 150 does not seem to work, so will check how the others are doing. You can check the code here: https://github.com/alexthissen/cc65/blob/serial/libsrc/lynx/ser/lynx-comlynx.s https://github.com/alexthissen/cc65/blob/serial/asminc/lynx.inc Once this checks out, I will submit a pull request to cc65. Thanks.

BTW, I do believe that the code in lynx-comlynx.s is flawed in a number of places. 1. Error on receive buffer overflow falls through into tx_irq routine and does not exit cpx RxPtrOut beq @1 stx RxPtrIn lda #SERIAL_INTERRUPT sta INTRST bra @IRQexit @1: sta RxPtrIn lda #$80 tsb SerialStat ; <------ Should exit irq, right? @tx_irq: ldx TxPtrOut ; Has all bytes been sent? cpx TxPtrIn See https://github.com/cc65/cc65/blob/3dfe0330003f19680f2afc9a607bea397b5c9fec/libsrc/lynx/ser/lynx-comlynx.s#L384 2. Baud rate for 31250 is incorrect as mentioned before 3. Duplicate code and inconsistent paths for resetting errors and ending IRQ 4. Asking for serial status does not return actual SerialStat value? SER_STATUS: ldy SerialStat ; <----- Should this be lda SerialStat??? ldx #$00 sta (ptr1,x) txa ; Return code = 0 rts I want to improve and fix the serial support, and verify my findings. All help is appreciated. Still working on a better version and running into more and more as I go along and understand everything better (at least, I think I do)

@42bs In your serial.inc code for new_bll it states: ldx RxPtrIn sta RxBuffer,x txa inx cpx RxPtrOut beq .1 stx RxPtrIn lda #$10 sta $fd80 END_IRQ .1 sta RxPtrIn lda #$80 tsb SerialStat See also https://github.com/42Bastian/new_bll/blob/fd69e5e04581bf661b552010661374333c3b36e2/includes/serial.inc#L109 I believe this code stores the value of A (which is loaded prior with the value of SERDAT) in the circular buffer at RxPtrIn and then checks if we overrun the out pointer RxOutPtr. If so, it adds an error flag to SerialStat. Was it intentional to set this to #$80? Why not #$08, which corresponds to OVERRUN as in SERCTL?

Also, I think that quite a few of the baud rates are incorrect. Working on improving that as well, including checking it on real hardware. ldx #2 cmp #SER_BAUD_31250 beq setbaudrate Especially here, it states that for 31250 baud, the calculation is off. The LDX should be #3 to get a countdown of 3 + 1 (for underflowing from 0 to virtual -1) before reload. The baud rate then becomes 1MHz/8 bits = 125000 bits per loop, which is 125000/4 = 31250 baud. For #2 this will be correct 125000/3 = 41667 baud. Also, for any other source period, some of the calculations are off as well. I will construct a pull request to improve the setting of baud rates.

For the past weeks I have been working on some updates in cc65 and focussed on serial communication first. I found this thread and it seems relevant again. I have some new findings on the behavior of the Lynx and ComLynx/UART. When sending data, the Lynx seems to respect all settings of even, odd, mark and space. On receiving the parity calculation is always done, even if parity is not enabled. It seems to be calculated correctly. From the EPYX documentation: "The state of the 9th bit is always available for read in the control byte. In addition, the parity of the received character is calculated and if it does not match the setting of the parity select bit in the control byte, the parity error bit will be set. Receive parity error can not be disabled. If you don't want it, don't read it" Control byte is SERCTL. The parity is available as byte 0 by reading from it. SERCTL surfaces three errors PARERR, Conclusions so far: Sending: PAREN is relevant and enables parity calculation if set. PAREVEN will be even parity, not setting PAREVEN means odd parity. If PAREN is not set, PAREVEN set will be MARK, and SPACE otherwise. Receiving: PAREN is irrelevant. Parity calculation is always done based on PAREVEN (or omission of it) for even/odd parity. It sets the PARERR bit in SERCTL when the calculation is failing. Calculations seems to be correct, despite the documentation stating that they made a mistake there. Especially with the second conclusion, the current implementation of lynx-comlynx.s is not correct. It always checks for PARERR as one of the errors, which should not be done for SER_PAR_SPACE and SER_PAR_MARK. Instead it should check the parity bit by reading SERCTL against a 1 (for MARK) or 0 (for SPACE). ; Excerpt from SER_IRQ in lynx-comlynx.s ldx SERDAT lda SERCTL and #PARERR|OVERRUN|FRAMERR|RXBRK beq @rx_irq tsb SerialStat ; Save error condition bit #RXBRK I might need some help in writing a proper control flow for the part above to not check for PARERR in SERCTL when receiving for the SER_PAR_MARK and SER_PAR_SPACE settings, and instead check the PARBIT (0x01, byte 0) by reading SERCTL and comparing it to 1 for MARK and 0 for SPACE and discard if different.